For translating the WineHQ.org website see TranslateWineHQ.
Wine binary files can contain the same resource in several languages.
Wine will choose which language to display based on user settings. For example, the command "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, which can be compiled with wrc (the Wine resource compiler). Usually there is a master resource file (e.g. programs/notepad/rsrc.rc) that contains language-neutral resources. There are also language files, which contain language-dependant resources in the given language (e.g. programs/notepad/En.rc (English); programs/notepad/Pl.rc (Polish)). Notice the LANGUAGE statement that instructs the resource compiler in what language the resources are. Before Wine 1.1.25, the master file #included all other .rc files, due to wrc not allowing multiple .rc files to be compiled at once.
You can check the Wine translations statistics page to see what's the state of translation into a given language.
Contents
1. How do 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 (check the WineOn64bit page), while on 32-bit systems all you need to do (usually) is
./configure && make depend && make
After building Wine you can run it from the source directory - e.g. run ~/wine-git/wine or ~/wine-git/wine program.exe (if the Wine sources are in ~/wine-git). You can also start built-in programs by running e.g. ~/wine-git/wine notepad. If you don't have Wine installed, you can install it by running make install as root from the main source directory. Then the Wine you have built can be started as just wine. However, if you have installed another version of Wine don't run make install (unless you remove the other 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 them 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. Find your 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 strings
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. If possible, always save in UTF-8 format.
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. A translation patch should contain changes to just 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 per 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 (e.g. editors like KBabel, Virtaal, etc) 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. Community based translations
You can involve your language community in the translation of WINE by making use of a web translation tool called Pootle. This allows you to expose the translations to user who can translate, review and make suggestions for translation. Pootle includes the ability to make use of terminology lists and to present progress statistics.
You need to have some sysadmin experience to setup Pootle, but once setup it will allow more people to help you translate WINE.
5. How do I test my translation?
See also: Testing languages.
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-git/) then you should change wine rundll32 ... to ~/wine-git/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. It's an ANSI program, and cannot display correctly UTF-8 (although it worked for files converted from ISO-8859-1 if the #pragma code_page(65001) is used). You can view all the dialogs to check 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
Another method to check your translation is simply to compile your changes by calling make and then use some resource editor, e.g. XN Resource Editor to open the compiled resource file (.res) or even the dll (.dll.so). At least XN Resource Editor opens them both without any problems.
6. 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.