Wine binary files can contain the same resource in several languages.
Wine will select the language version of the resource to display basing on user settings. For example "LANG=ru_RU winecfg" will launch winecfg in Russian (if you have Russian locale information installed in Linux/your other native system).
The resources are stored in Windows standard RC files. Usually there is a master resource file (e.g. programs/notepad/rsrc.rc) that contains language-neutral resources and includes language files. The language files contains language-dependant resources in the given language (e.g. programs/notepad/En.rc - English resources; programs/notepad/Pl.rc - Polish resources). Notice the LANGUAGE statement that instructs the resource compiler in what language the resources are.
You can check the Wine translations statistics page to see what's the state of translation into a given language.
Contents
1. How can I improve the translation
Wine is an Open Source project thus everyone can download the source code, modify the resource and send the modifications for a possible inclusion into the official Wine tree.
It is recommended to build Wine from sources to be able to test the translations. The recommended way to get the latest Wine source is to use Git. A quick guide to Git can be found at http://www.winehq.org/site/git. A more detailed one is at GitWine.
To build Wine you may want to first check Recommended Packages. On some 64-bit Linux distributions building Wine may be harder - you check WineOn64bit if you have one - while on 32-bit systems (if you have all the needed packages) usually all you usually need to do is
./configure && make depend && make"
After building wine you can run it from that directory - e.g. run ~/wine-src/wine or ~/wine-src/wine program.exe (if the Wine sources are in ~/wine-src). You can also start built-in programs by running e.g. ~/wine-src/programs/notepad/notepad. If you don't have Wine installed yet you can install it by running from the main source directory as root: make install. Then the Wine you have built can be started as wine. However if you distribution ships Wine you shouldn't run make install (unless you remove the "official" Wine first) as this may lead to conflicts
If you are able to build Wine you can try to edit the resource files. If you are adding new resources to an existing file, copy then from the English file and translate the strings. If you are translating a new file:
copy the English file as your file (let's say Qq.rc)
run "git add Qq.rc" for Git to know about this new file
add an #include "Qq.rc" to the master file (usually rsrc.rc)
run "make depend" for make to know about the new file
modify the LANGUAGE line. Lookup you language code in include/winnt.h and the sublangage rule for your language on SublangNeutral (or copy them from another file in your language)
- translate the string
Guidelines about editing these resource files and which strings should be translated are in the Translating chapter of Developers-Hints. Note that as stated on that page, unless changed explicitly with a pragma, the files are not in UTF-8 (the Linux/MacOS X standard charset) but in the Windows encoding.
After editing the resources you should do a make to check if Wine builds and runs correctly. If you translated a program you can run it and check the translation. You can commit the changes to your local Git repository with git commit -a. You can check the changed after the last commit with git diff HEAD. It's good for a translation patch to contain changes to one dll/program so it's best to commit the changes after translating one dll/program and before moving to another.
If you are satisfied with your translations you can send it to wine-patches and they might get included into the official Wine Git. Read on http://www.winehq.org/site/sending_patches about how to do it and how to check if it got applied. Send only patch files (e.g. generated by git format-patch), one in a mail, without compression (if the patch in your mail won't be recognized and applied by an automated script then the chances of it to be accepted are close to zero).
2. Using PO files to translate Wine
If you are more familiar with the PO files used by most FOSS programs, and want to make use of your existing localization tools and resources (Translation Memory, glossaries, etc) then you can now also translate .rc files using Gettext PO.
The program rc2po which is part of the Translate Toolkit will convert a .rc files into a .po file. It can also recover translations from your existing .rc translations.
The simplest way to work with PO files is firstly to follow most of the instructions on this page about Git commits, Lang and Sublang advice. But at the point of editing the .rc file you will do the following:
- rc2po En.rc Qq.po (we make a PO file and use the same Qq naming convention as in the examples above)
Now translate Qq.po in your PO editor (KBabel, PoEdit, etc)
- po2rc -t En.rc Qq.po Qq.rc (will convert your PO translation to .rc)
You can also recover your old translation if they have got out of date, note that you will have to review all translations not just untranslated entries.
- rc2po -t En.rc Qq.rc Qq.po (this will recover your translation into Qq.po)
- Translate missing items and review EVERYTHING else in Qq.po
- po2rc -t En.rc Qq.po Qq.rc (and you have an updated .rc file in your language)
3. Where can I find more help on translation?
Translating or localizing for those who are new to it can be daunting. The Localization Guide provides much help for those who are starting to translate for the first time.
4. How can I test my translation
If you translated a program you can run it and check the translation. If this is a DLL and you don't have the experience what program may be using it then it is good to test at least the dialog if the text isn't too big for the control rectangles. This can be done by creating a fake DLL and using a resources viewer/editor to view the resources.
A fake DLL can be created by the script makefake.sh. If you are using Wine from your source directory (let's say ~/wine-src/) then you should change wine rundll32 ... to ~/wine-src/wine rundll32 .... Calling ./makefake.sh comdlg32.dll will create in the C:\windows\system32 directory of your wineprefix a file comdlg32.dll that will contain no code but only all the resources (that is a so called fake DLL). If you type an invalid name (e.g. ./makefake.sh abcdef123.dll) then a fake DLL will also be created but with no resources. The names of modules are obtained from the name of directories by appending .dll for subdirectories of dlls/ and .exe for subdirectories of programs/.
Resources inside such a file can be viewed by special programs. An example of such a program that I know of and that can be freely downloaded is ResHacker. Unfortunately it is an ANSI program what means that string in other languages may display incorrectly, but your language should display fine. You can view all the dialog if they display fine. Languages are on the third level of the tree on the left and are identified by numeric IDs. Such an ID can be computed as language_id+1024*sublang_id where the numerical language and sublanguage ids are defined in include/winnt.h
5. What if a resource is missing
- If the whole resource (e.g. whole dialog or menu) is missing then the resource loader will try next languages on its list what usually means that the English (US) resource will be loaded
- If e.g. a menu is missing an item or a dialog is missing the control then the menu/dialog will display without this item. This can cause the translated version to the program to be somewhat broken. Such resources will be marked as out-of-sync in the translation statistics.
- Stringtables are tricky as they come in packs of 16. Up to sixteen strings (the resource can have empty slots) based on their numeric ids are placed in a single resource. This often causes missing strings to fall into category 2 instead of 1. Such cases are also marked as translation out-of-sync by the statistics. What strings are together in a physical resources may not be easy to read from the resource file but is shown by the statistics page. A missing string could cause the translated program to e.g. display a message box with no text but only a question mark icon and buttons Yes and No.
As we see fixing out-of-sync resources is maybe even more important than translating new resources (however the current version of statistics have probably some false positives - e.g. some Korean dialogs are marked as out-of-sync because they declare a font when the English version doesn't. But they probably need to for the Korean characters to display. But it would be good to have a confirmation). To avoid out-of-sync situations some developers add resources (especially strings to stringtables) to every language file. Such entries are not marked by the statistics page as missing - you should review the resource files manually.