1.1 Getting the list of supported languages

The naming convention for the languages follows the ISO 639-1 standard, for which you can find a summary list in the GNU gettext manual.

But as WINDOW MAKER does not support all of them, the configure script will print a warning for each language you specify that it does not know, and sum up at the end the list of enabled languages that will be installed.

There is a non-standard possibility to set LINGUAS to list, in which case the configure script will provide you the list of languages it supports, and stop:

./configure LINGUAS="list"

There is also another non-standard possibility to enable all the languages that WINDOW MAKER supports by setting LINGUAS to *. This is an internal trick implemented so the development team can have the command make distcheck include some checks on translations:

./configure LINGUAS='*'

1.2 Translations for Menus

In order to propose an Application Menu (also called Root Menu) that is also translated in the language of the interface, WINDOW MAKER implements two complementary mechanisms:

The first, always enabled when i18n support is enabled, is to look for the menu file containing the name of the locale. For example, if the file is called menu and the language is set as LANG=fr_FR.utf-8, then WINDOW MAKER will search for, and use the first match found:

• menu.fr_FR.utf-8

• menu.fr_FR

• menu.fr

• menu

The second possibility, which is not enabled by default, is to be able to use a custom po file which contains the translations for the text of the menu. This feature is enabled at compile time, using the option --with-menu-textdomain to the configure script. For example, if you specify:

./configure --with-menu-textdomain=WMMenu

then the translations for the menu will be searched in the file WMMenu.mo located at the standard location, the default path being PREFIX/share/locale/[lang]/LC_MESSAGES/WMMenu.mo.

If you do not enable the feature (the default behaviour, or with an explicit --without-menu-textdomain), then WINDOW MAKER will not try to translate the strings, even using its own domain file (WindowMaker.mo).

1.3 Setting LINGUAS at system level

As the variable LINGUAS is quite standard, you also have the possibility to set its value in the config.site file for AUTOCONF. This file can be placed in one of these paths:

• PREFIX/share/config.site

• PREFIX/etc/config.site

This way, the same language list will be used for all the programs that use AUTOCONF that you would compile. Please note that if you also specify a value on the command line, it will have precedence over the value in that file.

4.1 Install the latest sources

If you want to contribute, the first step is get the development branch of the code; this is done using git. If you do not feel confident at all with using git, you may also try to ask for a snapshot on the developer's mailing list [email protected]. With git the procedure is:

# Get your working copy of the sources
git clone git://repo.or.cz/wmaker-crm.git

# Go into that newly created directory
cd wmaker-crm

# Switch to the branch where everything happens
git checkout next

# Generate the configuration script
./autogen.sh

Now you should have an up-to-date working copy ready to be compiled; you will not need to go the full way but you should run the configure script, so it will create the Makefile`s, and you may want to compile the code once so it will not do it again automatically later while you are doing something else:

# Setup the build, enabling at least the language you want to work on
./configure LINGUAS="<list of iso 639 country code>"

# Compile the code once
make

4.2 Updating the Translations

The typical process for translating one program is:

• generate a POT file (PO Template): this is done with xgettext which searches for all the strings from the sources that can be translated;

• update the PO file for your language: this is done with msgmerge which compares the PO file and aligns it to the latest template;

• edit the new PO file: this is done by you with your favourite editor, to add the missing msgstr, review the possible fuzzy matches, …

• check the PO file: unfortunately there is no definitive method for this;

• submit your contribution to the project: this is done with git.

In WINDOW MAKER, you have actually 4 po files to take care of:

• po/<LANG>.po: for WINDOW MAKER itself

• WPrefs.app/po/<LANG>.po: for the Preference Editor program

• WINGs/po/<LANG>.po: for the graphic toolkit library

• util/po/<LANG>.po: for the command-line tools of WINDOW MAKER

As stated previously, there is a make target that can help you to automatically generate the POT and update the PO for these 4 cases:

make update-lang PO=<LANG>

Once run, it will have updated as needed the 4 po files against the latest source code. You may wish to use the command git gui to view the changes; you can now edit the files to complete the translation, correct them, remove deprecated stuff, … Please note that the encoding should be set to UTF-8 as this is now the standard.

If you think an error message is too obscure, just ask on the developer mailing list [email protected]: in addition to clarifications there's even a chance for the original message to be improved!

You may find some information on working with po file in the GNU gettext documentation.

4.3 Translate the Man Pages

You may want to extend the translation to the documentation that is provided to users in the form of Unix man pages. The sources of the man pages are located in the doc/ directory; the translation should be placed in the directory doc/LANG/ with the same file name.

The directory will also need a file Makefile.am which provides the list of man pages to be included in the distribution package and to be installed. You can probably get inspiration from an existing one from another language; if you do not feel confident about it do not hesitate to ask on the project's mailing list ([email protected]), either for help or to ask someone to make it for you.

Please note that although most man pages sources are directly in man page format (nroff, the file extension being a number), a few of them are processed by a script (those with the .in extension, like wmaker.in). This is done because in some case we want the man page to reflect the actual compilation options.

You may not want to bother with this hassle, in which case you can simply name your translation file with the .1 and remove the special @keyword@ marks. If you are sure you want to keep that processing but do not feel confident about hacking the Makefile.am do not hesitate to ask on the project's mailing list ([email protected]).

4.4 Checking the Result

In the WINDOW MAKER build tree you also have another target that can help you, it is make check.

At current time, it does not check much, but if during the make update-lang new po file have been created you may get some errors, because you have to add these new files to the variable EXTRA_DIST in the corresponding Makefile.

If you do not feel confident about doing it, do not worry, just tell about it when you submit your work, and some developer on the mailing list will just be happy to do it for you when integrating your valuable contribution (we always like when someone helps making WINDOW MAKER better).

4.5 Submitting your Contribution

Preliminary Remark: if the update process made changes in a po file but you did not change any msgstr content, it is probably a good idea to not submit the changes to that po file because it would just add noise.

When you feel ready to send your changes, the first step is to prepare them. This is done with git: if you have not run the git gui previously then it is a good time to do it now. This window offers you the possibility to show your changes and to decide what you want to send.

The window is divided in 4 panes:

• top-right show the current changes you have selected, for review (and also for cherry-picking stuff if you want to select precisely)

• top-left ("Unstaged Changes") the list of files with changes to be send, you can click on the name of the file to see the changes, you can click on the icon of the file if you want to send all the changes in this file; an icon in blue shows a file that have been changed and an icon in black shows a file that is new

• bottom-left ("Staged Changes") the list of files with changes that you have chosen to send so far, you can click on the file name to view these changes, you can click on the icon if you want to remove the changes from this file from the list to send

• bottom-right ("Commit Message") the message you want to attach to your changes when you submit them to the development team

The idea here is to pick your changes to the po files; for the commit message you may wish to stuck to a simple, single line:

The penultimate step is to click on the button Sign Off (it will add a line in the commit message), and then click on the button Commit. From this time, the commit message will clear itself and the "Staged Changes" also, showing that your action was done.

You may now quit the git gui, the final step begins by running this command:

git format-patch HEAD^

This will generate a file named like 0001-updated-translations-for-XX.patch which contains your changes, ready for sending. The goal will now be to email this file to [email protected]. If you feel confident in having git send it for you, you may want to read the file The-perfect-Window-Maker-patch.txt to see how to configure git for mailing, so you can run:

git send-email 0001-updated-translations-for-XX.patch