VOICE Home Page: http://www.os2voice.org |
August 2005
Newsletter Index
|
By Jacques van Leeuwen, Jan van der Heide © August 2005 |
For a good and broad acceptance of many programs, it is necessary to have those programs available in the native language of the user. That works a lot easier and quicker for her/him, most of the times. Although many users speak a second or a third language, there still is a large group that does not understand English well enough, for instance, to understand the programs, screens and helptexts. Thus they cannot work well and efficiently with them. This group of people would be excluded as users if the programs are not available in their own language.
If programs are available in other languages, they are said to be NLS-ready. NLS stands for National Language Support (support of own language). The programmer should already keep in mind that the program could be made available in other languages while coding. The strings should therefore be kept outside the actual program, for instance in seperate DLLs or MSG files. By using links, those strings are loaded into the program, although that can still cause problems because of the string length. English is a very compact language and a growth in string length of 10 to 30% during translation is not uncommon. But this is an area which goes beyond the scope of this article. This would better fit in an article about programming in relation to NLS.
Many of the translatable strings can be found in so-called resource files.
These are a kind of program files, in ASCII format, which are compiled into
help files, menus, dialogs, etc., that you see when using the specific
program. These files can exist in various formats. Standard versions are the
.RC and .DLG filetypes. But for eCS also .HTML and regular text files (.TXT,
.ME, etc.) are used.
For a good translation, everything should be translated. This includes the
command files (.CMD) which are used as text files to perform installations
and create the Desktop objects, for instance.
Don't worry and don't think that you need to be able to program
to start translating. That is not required by any means. The strings that should be
translated are mostly very easy to recognize. In case an error is
made, then most of the times it is very easy for the programmers to find them
by processing the translated strings.
Beyond the program-specific technical documents, the help files also need to be translated. These are quite often either .HTML files or a so-called .IPF file. The seperate HTML files are converted into one IPF file, which is then again converted into an INF or HLP file. The extension INF stands for a so-called 'Information' file. Both the .INF file and the .HLP file have the same file format and can be read by the same program, for instance NewView.
In window menu bars, pull-down menus, pop-up menus, dialogs, etc. letters with underscores exist. These are called 'Mnemonics', which means a memory aid. That means that the underscore letter is very typical for the specific word or expression (it is usually the first letter). In addition, expressions exist that are displayed after the menu items in pull-down menus, e.g., Print Ctrl+P with an underscore under the 'P' of Print from the pull-down menu File in the menu bar. The key combination [Ctrl+P] is called a shortcut. The 'P' with underscore is called a mnemonic.
The key combination [Ctrl+P] is hard-coded in the programs and can be used to print something at any moment while using the specific program. To do so, the drop-down menu belonging to File doesn't have to be 'open.' If the pull-down menu is 'open,' you can press the 'P' to get the Print dialog as well. This option to use an underscored letter in a pull-down menu or pop-up menu and then open a dialog quickly exists for all pull-down menus or pop-up menus wherein underscored letters exist.
The menu bar, mostly the second bar in the window, displays options like File, Edit, etc. which contain pull-down menus that can be opened in two ways:
Shortcut combinations expressed with [Alt+...], [Ctrl+...], and [Shift+...] cannot easily be translated most of the times. Mnemonics, an underscore letter in a pull-down or pop-up menu, might need to be translated, meaning that a unique letter should be assigned. Most of the times this requires a thorough search and test exercise. In specific situations, the authors of this article are very willing to help you further.
Translating a stand-alone program is not too complicated most of the times, especially if it isn't too large. It is a lot more complicated to translate all programs in the same and consistent way, though, so basic terms are named the same in each program, e.g., Close, Edit, Configuration, etc. This is expressed by the term CUA (Common User Access).
Using the same expressions is far from easy, especially if various people are translating at the same time. Most people have their own translation for the same English words. Therefore this has to be checked thoroughly, in the light of the fact that dictionaries list multiple translations for one word as well. It is therefore handy and advisable to work with a word list. This can be a spreadsheet, a database, or a comma seperated file. Also a seperate website, reachable by all translators, is an option.
The start of such a list and extending it is actually the most important thing
before starting the actual translations.
This list is also known as a 'Terminology list'. It can be arranged for just
one program, but also for a set of similar programs. It should contain the
specific English terms that occur in the programs with their respective
translation(s).
With this list as a start, which certainly is not the only source, various
people can start translating in parallel. Get agreement on newly found words
from the others as soon as possible and add them to the word list, which
can be used directly.
During the translation work for eCS 1.2 NL we already started, as an
experiment, with an online word list (see http://netage.nl/translate, userid:
guest password: readonly).
This list is only conceptual at the moment and needs to be built on further,
but it can surely be used as a starting point for the future. The big advantage
of such an approach is that multiple languages can be connected to each other in
one single system by which it is easy to switch between those languages.
Next to the already mentioned word list, there of course are various other
possibilities to achieve a uniform translation. You can think of dictionaries
(especially computing specific dictionaries).
For using the correct spelling a spell-checker is a must and next to the
'Word list Dutch Language' (the so-called Groene boekje) books about grammar
could be used as well. An important thing about this is that people are using
the same publication/edition, otherwise differences might still occur. It is of
course uncertain if this kind of books is available in the specific language.
After things have been translated, everything should match the original
version, of course, as well as be understandable.
You yourself are reading your translations a couple of times and are testing
things, of course, but still you will be 'blind' to your own translations and
won't recognize and see mistakes. It is advisable to have your work read
and tested by others as well. Most of the time, that improves quality
considerably.
For the Dutch version of eCS 1.2, the files to be translated were divided among members of a translation group. These were exchanged after translation, by which a kind of cross-check was established for terms used as well as style. Something to agree upon is how remarks should be communicated, so that it is clear what is meant and where things should or could be improved.
For eCS 1.2 NL, we always used editors that support line numbers (MED or EPM for instance) and we stated in which line of a named file something was wrong or could be improved, for instance:
XFLDR031.RC: Folder -> Map (414),
with
This method proved to be very functional.
It is not advisable to directly change somebody else's texts, as most of the times it is not very clear anymore what has been changed and the correct translation cannot be used in the rest of the process as well. And there is also the risk of introducing new mistakes in the text.
Explaining the reason for a change is also advisable. A hint might be that ASCII files can be easily compared using a program. A handy program for this is GFC (Graphical File Compare) which uses colors to show the differences between the two files.
After things have been translated and released, the original (mostly English) program will be updated, extended, or improved most of the times. That will mostly also have consequences for the NLS files. It is important that a kind of version control system is used, by which the original files are kept to be compared with the new versions (for instance with GFC). Thereby changes can be found quickly as well as what needs to be changed in or added to the translated documents.
This method is not used yet within the eCS 1.2 NL translation process, but will surely be used for the next version of eCS, or the seperate components within.
Translators need to be fluent in both languages for good translations. That makes translating a lot easier. Thereby it is not continuously necessary to check a dictionary or a word list. Something that is used a lot in the Dutch language are proverbs and sayings. Try not to use them, because it is very hard to find a good matching one in another language most of the times.
Especially if a lot of text has to be translated, it is handy to know who is doing what and where people can go with questions, suggestions about translations, translating new terms, and such. Quite often translators can add their name and email address in the translated stuff, but not everybody likes that, or there is not always place for it. Next to that it is also possible to add something to your mail signature stating that you are part of a translation group. An example of that can be: Member of the Dutch eComStation Translation Group (Lid van de Nederlandse eComStation Vertaalgroep).
But be careful, before you know it, work piles up. Also remember that
others can volunteer for translating by which the translation work (which is a
lot of fun to do) is made easier.
A handy communication tool between translators might be a private IRC channel;
then people can put their heads together virtually and quickly.
A lot of background information is given above, in various areas, in relation to translating. It is handy to think about a number of things though, before you start the diligent translation work.
Look at which books and other referential material is available or are used by other translators.
Make a list of words used within the program to be translated. Start up the original English program and register the content of all dialogs, screens, pop-up menus, etc. Note the context in which the found English expressions, texts etc. exist, as well as possible. An expression of which a letter has an underscore is included in the text file with a '~' (tilde) in front of the respective letter. But if that letter also occurs in the translated text is very doubtful. The authors of this article are very willing to help you further.
Prepare a word list of translations to be used (terminology list).
Make that list available to the translators.
Make a list of the used mnemonics within the program to be translated.
Prepare a mnemonics list of translations to be used (mnemonics list).
Make that list available to the translators.
Distribute the files to be translated and agree upon a way of working/passing them on.
Start translating.
Pass your work on.
Check the work from others and give remarks and adjust the word list and mnemonics list.
Finish translations and send, if applicable, the outcome to the programmer(s).
Go have some fun with the other translators to celebrate the finishing.
In the near future, translators will also be able to use CVS (Concurrent Versioning System).
References:
|
Feature Index
editor@os2voice.org
< Previous Page | Newsletter Index | Next Page >
VOICE Home Page: http://www.os2voice.org