Excel export format
In version 4.60.0024 (for VS 2005/2008) I have added a new Excel export version.
At present, this means that there are three different excel export/import versions. I appreciate that this will be confusing, so don't intend to leave it like this for long.
If users prefer the new version, I will make it most prominent (and hide the others in a submenu, or even remove them).
The background is, that the 3 worksheet export, which includes macros in the workbook, has not been well received by all users. In particular:
- Macros are unpopular and have a bad reputation. In some organizations they are positively forbidden.
- There is some doubt about the reliability of the macros.
- The format is too complicated, and requires too much explanation.
On the other hand, the original single worksheet format is too primitive. It provides absolutely no context information for the translator. By context information, I mean some indication of where a string is used.
What I wanted was simple a format which indicated where each string was used. The biggest difficulty is, how to handle strings which are used at multiple locations in a project.
My decision was that if a string is used multiple times in a project, then is should be exported multiple times to the Excel file. Compared to the original format, the new format contain two new columns:
- Location, which indicates where the string is used
- Multiple usage, which indicates whether the string is used multiple times. If a string is used multiple times, then this column has a coloured background.
The header on the worksheet now contains only one line (not two as previously). This makes it easier to sort the worksheet.
Sorting the worksheet is in fact an important feature. This is easy to do using Excel. If you sort the worksheet by the Location column, then texts are grouped according to where they are used. This is the initial state. If you sort the worksheet on the ID column, then strings which are used multiple times are grouped together. This makes it easy to copy the same translation into all occurrences.
The disadvantage is, that you would have to copy the translation into all occurrences. This is one of the things which was handled automatically in the version with macros. (Alternatively, you could actually delete the duplicate lines, but I am not sure this a good practice.)
What if the translator decides to enter different translations for same string ID, at different locations in the project? I think that that is quite legitimate. The import operation will check for this situation and will create new String IDs if required. This makes the import more complicated, but it is an important feature.
Between exporting to Excel and reimporting the translations it is better not to make changes to the project, at least no changes which modify the line numbers. If all translations for a string ID are identical, then the Location column is not required for the import. If multiple occurrences are translated differently, the import operation has to use the Location column to find the exact location.
Phil