View source for Translation

HOWTO: Translating GnuCash<br>

The concept of this document is to give you step-by-step instructions on 
how to update (or create if non-existant) language translations for the 
gnucash project.  See [[Translation Status]] for the current status of the project with respect to translation contributions.

== Available resources ==
There are many resources to support you at gnucash.org and other places. Don't hesitate to use them.

=== gnucash.org ===
We have collected a bunch of useful information for you here in this wiki -
:navigate from the [[GnuCash|main page]] or use the search function -
and on the website [http://www.gnucash.org http://www.gnucash.org].

And we have several channels of communication and a few other useful tools:

==== IRC ====
The fastest way to get help is using the '''internet relay chat''' [[IRC]], as many of the developers hang out there and are eager to help.

==== Mailing lists ====
Translators will probably find two or three gnucash mailing lists of interest. If you can not find the answers to your questions in their [[Mailing_Lists#Mailing List Archives]], feel free to ask them.
* For ''language and region specific questions'', where you should discuss terms and ask for proofreading of your work, use your languages mailing list. Currently we have
*: '''gnucash-'''[pt_]'''br''',''' de''',''' es''',''' fr''',''' it''',''' nl'''.
: If none exists for your language or nobody has an answer there, use the english lists:
* ''General use questions'' and answers are found on the '''gnucash-users''' mailing list,
* specific ''development questions'' go to the '''gnucash-devel''' list.
* If you dislike the heavy traffic on the above lists, you should at least subscribe the [https://lists.gnucash.org/mailman/listinfo/gnucash-announce gnucash-announce] list to get informed about new releases.

To ''subscribe'' or ''view archives'' of these lists follow the links to the [[Mailing Lists]].

== Translatable Files ==

GnuCash has several separate areas that need translations or localization:
* The [[#Translating the Program|program]]'s message catalogs: These control the user interface of the program itself and consists of ~4k strings. But not all are really important.
* A [[#How to translate the Windows Installer|Windows Installer]] with ~20 strings.
* The [[#How to translate the files containing the new account hierarchies|Account Templates]]: This is a set of pre-built sections of charts of accounts which are presented to the user when she creates a new file.
* The [[#Translating the GnuCash Guide and Help|documentation]]: the Help Manual and the [[Concept Guide|Tutorial and Concepts Guide]]. These documents explain how to use GnuCash. They are written in DocBook, an XML variant.
* The [[#How to translate the website|website]], while mostly written in PHP/HTML, uses message catalogs, too.
* [[#How to create localized Income Tax Tables|Income Tax Tables]] require some knowledge of your regional tax rules.
* Optional you can translate [[#Check doc/README-*|doc/README-*]] files, too.

=== Coordinating Message Catalog Translations ===

==== GNU Translation Project ====
The [http://translationproject.org/ GNU Translation Project] coordinates certain translations; you can see which ones on their [http://translationproject.org/domain/gnucash.html GnuCash page] and learn about their process [http://translationproject.org/html/translators.html here].

If you want to help with a Translation Project translation or add a new translation under their aegis, please contact the language team using the information on their [https://translationproject.org/team/ team page].

The Translation Project requires that you use either an existing translation or <tt>gnucash.pot</tt> from the latest release as the basis for your translation.

==== Direct Contribution ====
If you want to work on a translation that's not coordinated by the Translation Project or a new translation and you want to submit it directly to GnuCash, read on. If it's an existing translation please try to contact the last translator first using the contact information in the message catalog.

If you're starting a new translation it's much easier to begin with a tarball, which will include <tt>po/gnucash.pot</tt>; if you start from a [[Git]] clone you'll have to [[Building|build]] Gnucash yourself first to generate <tt>gnucash.pot</tt>.

=== Coordinating Account Templates and Documentation ===
The Translation Project handles only message catalogs, so if you have account template or documentation translations you'll submit them directly.

== How to submit changes directly to GnuCash ==

Once you've got a translation ready for submission, there are three options:

=== Patches at Bugzilla ===
The easiest and safest way is to use [[Bugzilla]]: [http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash&component=Translations&bug_severity=enhancement Create an ''request for enhancement'' bug against the Gnucash component translations] and attach a patch
containing the diff between the old files - if any - and your new files. The easiest way to create the patch is <code>git format-patch origin/maint..maint</code>. See [[Git]] for details.
 
=== Pull Requests at Github ===
If you already are a github user you can publish your work as a separate branch on your gnucash[-{[ht]docs|on-windows}] fork and send a pull request. If you wish to continue your work  before the request was completed, simlply create a new working branch. After the pull request was completed you can delete that branch again. Again, see [[Git]] for details.

=== Mailing lists ===
You can simply email your completed message catalog (<tt>.po</tt> file) to the developers at the [mailto:gnucash-devel@gnucash.org gnucash-devel] mailing list. We'd really rather you use Bugzilla or Github because those are much less likely to get lost or forgotten, but if you really find those too hard we'll try to accommodate you on the list.

== General Translations Guidelines and Tips ==
General information about how to approach the translation of software can be found here:
* GNU/Free TranslationProject
** http://translationproject.org/html/translators.html
** http://translationproject.org/html/software.html
* Gnome
** Human Interface Guide https://developer.gnome.org/hig/stable/
** GNOME Documentation Style Guide https://developer.gnome.org/gdp-style-guide/
** https://wiki.gnome.org/TranslationProject
** https://wiki.gnome.org/TranslationProject/LocalisationGuide
* KDE
** http://l10n.kde.org/docs/translation-howto/index.html

=== Other Useful Sites ===
* There are many online dictionaries, use a search engine like google, to find the best fitting.
* An index of on-line dictionaries and a lot of other resources can be found at www.yourdictionary.com. 
* Comparing articles on wikipedia in your language and english can be helpful.
* In special cases the terminology database of the European Union [http://iate.europa.eu/iatediff/SearchByQueryEdit.do Inter Active Terminology for Europe] can be used, too.

== Translating the Program ==

To begin a translation you need either the message template file (gnucash.pot) if you're starting a new translation or the existing message catalog (xx.po or xx_YY.po, where xx is the ISO code for your language and YY the ISO code for a language-variant locale, see [[#Naming Convention|Naming Convention]]). These files are in the gnucash sources, which you can obtain either from our [https://github.com/Gnucash/gnucash.git git repository] or by downloading the latest '''release''' tarball from [https://www.sourceforge.net/projects/gnucash/files/gnucash%020(stable) Sourceforge].

=== Get the source from Git ===

GnuCash uses [[Git]] as a version control system. [[Git|Click here]] for an introduction to Git.

The first thing to do is ''usually'', to download the latest STABLE branch, called '''maint''', of gnucash from git and get it to compile.  '''See [[Translation Status]] to choose which branch to use for translations'''.  Do not use the ''master'' branch ''unless specifically mentioned in [[Translation Status]]''.  Because the text in the ''master'' branch changes so much it would be a waste of time to translate  it.  Do not worry, when the ''master'' branch becomes stable the existing  translations in the STABLE branch will be merged.  Your work will not be lost.

Normally checkout the current stable branch if there is one:
 git clone <nowiki>https://github.com/Gnucash/gnucash</nowiki> gnucash-git
 cd gnucash-git
 git checkout maint

The argument "gnucash-git" above can be whatever you want your local directory to be called,
and is optional. If you leave it out, you'll have a directory called "gnucash" created
containing all the source code below your current working dir.

Checkout the documentation (optional, but recommended):
 git clone <nowiki>https://github.com/Gnucash/gnucash-docs</nowiki> gnucash-docs
 cd gnucash-docs
 git checkout maint

==== Update your repository ====

After this initial git checkout, you can later update your local files using
 git pull --rebase
e.g. if you noticed, the developers changed some strings.


=== Get packages, which are used while building  ===

[[Dependencies]] contains the list of packages, which are used while building GnuCash. Under Linux use your package manager and install that, wich are missing. Otherwise [[#autogen.sh]] or [[#configure]] will fail.

=== Steps in the Build System ===

Most parts of GnuCash and it's documentation are using the GNU Autotools as build system. Details are described in [[Build System]].

==== Initialize the Autotools ====

Before you can use commands like <code>make <target></code> you must configure the build system. This way you can get your system set up correctly with all the development packages you need.

===== autogen.sh =====

Enter the gnucash directory and run the autogen.sh script.  This will do a few checks and generate the configure script.  If it fails to generate the configure script then you are probably missing a bunch of development packages, like ''libtool gettext intltool automake autoconf'', or any of the ''-devel'' packages that supply the various autoconf macros that gnucash requires. See [[Dependencies]] to find the development packages for your system, install them, and then re-run autogen.

Note: there are some warnings that spew forth during autogen.  Do not worry about them, apparently they are normal and can be ignored.

;Attention!: If you are building GnuCash more than once, you will have to redo these steps every time, you ''updated'' parts of your build system or libraries on which GnuCash depends.

===== configure =====

Once you create the configure script, you should run it.  There are many options available when compiling gnucash, see the README.git file for more information on the options.  For now, we will just enable debugging and change the default prefix because these two changes will be handy later for tracking down problems and installing multiple versions.

 cd gnucash
 ./autogen.sh
 ./configure --enable-debug --prefix=/opt/gnucash-git

If configure complains about '''missing development packages''', find them on your favorite OS/distribution, install it, and try to re-run the configure command.
See your local copy of the [https://github.com/Gnucash/gnucash/blob/trunk/README.dependencies README.dependencies] file for library dependency notes.
Also check out [[Dependencies|the dependencies page]].
Eventually, you should be able to get autogen to run without any error 
messages.

==== Optional Compile & Install ====

It is suggested that you compile the gnucash source code. It is a good idea to actually run gnucash with your new translations because it is quite helpful to see the phrases in the context of the running program. 

===== make =====

Next, compile gnucash:

 make

===== make install =====

To install (assuming "make" completed without any problems) somewhere else than in your home directory you must be root:
 su - 
 make install

After you succeeded, you can leave the SuperUser mode with
 exit

To compile the documentation, enter the gnucash-doc directory and go 
through the same process:
 ./autogen.sh
 ./configure --prefix=/opt/gnucash-git
 make
 su -
 make install
 exit

===== Running GnuCash =====

After installation, insure that it works by running (as a normal user,
no need to be root here):

 /opt/gnucash-git/bin/gnucash

It is a good idea to use absolute paths like this to insure you run 
the proper gnucash executable.  To run your OS pre-installed version of
gnucash, usually you can type:

 /usr/bin/gnucash

In either case, you can easily switch between the various languages the 
gnucash has available by placing the LANG env var before the call to the
executable. You can find details in [[Locale Settings]].

=== Naming Convention ===

The language code is of the following form:
:<language>[_<REGION>][.<Charset>][@modifier]
using the well known ISO codes [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes 639-1] for ''languages'' and [http://en.wikipedia.org/wiki/ISO_3166-1 3166-1] for ''territories''. Only ''if no 2 letter code exists'' for your language in 639-1, you should use the 3 letter code from [http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes ISO_639-2].

If you are the first translator for your language, you should name your files and directories ''only with your language code''. So all people using your language despite of their country will benefit from your work.

If there are parts, which are ''specific for your country'', e.g. business account templates respecting local law, then they should be in a <language>_<COUNTRY> directory.

The common '''charset''' in gnucash is [http://en.wikipedia.org/wiki/Utf8 utf8].

In the rare case ''different scripts'' are used for the same language like kyrilic and latin add for the less used the '''modifier''' e.g. <tt>sr@latin</tt>.

In the following parts of this document 'XXXX' and 'LL' refer to your language code.

=== Contact the maintainer of your language ===

To find out who is the last person to work on your language, look near the 
top of the po/XXXX.po file which corresponds to your language.   If your 
language does not have a .po file available, see the next section.

The beginning of your .po file should look something similar to this:

 # Localization for Portuguese-Brazil
 # Copyright (C) 2003 Free Software Foundation, Inc.
 # Jon Lapham <lapham@extracta.com.br>, 2003
 # Jose Carlos Nascimento - <joseca@psabs.com>, 2001.
 # 
 msgid ""
 msgstr ""
 "Project-Id-Version: GnuCash 1.8.3\n"
 "POT-Creation-Date: 2003-05-16 16:42-0300\n"
 "PO-Revision-Date: 2003-06-02 12:00-0300\n"
 "Last-Translator: Jon Lapham <lapham@extracta.com.br>\n"
 "Language-Team: NONE \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=ISO-8859-1\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=n != 1;\n"

Look to see who the "Last-translator" was, and send an email to that person 
and ask what you can do to help.  This is important because if there already 
is an active maintainer of the translation file, you should interact directly
with him or her.  If there is no Last-Translator, or that person is not 
maintaining the file actively (and tells you to take over or does not answer in reasonable time), you will become 
the maintainer and you should change the "Last-Translator" to your name and 
email address.

=== The glossary file ===

Inside the po/glossary/ directory should be a "glossary" file for your 
language.  This file contains a bunch of ''commonly used terms'' found in GnuCash - and the explanation of a few very specific for GnuCash like the disambiguation between ''bill'', ''invoice'' and ''voucher''.
It is recommended that you '''get this file translated first''', and use it as a 
guide when translating the real .po file or the documentation.  Please keep in mind that this file will ''never be visible to a user''! The glossary file is only a tool for you, the translator! I repeat: The strings from the glossary file will ''never'' be user-visible, they are only used by you, the translator.

Go into the glossary directory and rebuild your language's glossary file:

 cd po/glossary/
 ./txt-to-pot.sh gnc-glossary.txt > gnc-glossary.pot

If your .po glossary file does not exist, use this gnc-glossary.pot file to
create it:

 cp gnc-glossary.pot XXXX.po

If your .po glossary file does exist, use the msgmerge program to update it:

 /usr/bin/msgmerge -o XXXX.po XXXX.po gnc-glossary.pot;

Now, open your language's glossary file and translate it completely.

==== Terms missing or inadequate in the glossary file ====

If you detect an important term which is missing or could be better explained, [[Bugzilla#Using_Bugzilla|open a bug]] and add a [[Git#Patches|patch]] for the ''source file'' '''gnc-glossary.txt'''.
The - with the exception of the headline - alphabetical sorted lines of this file have the form:
 Msgid<TAB>Comment

To test it, run the following steps after you changed gnc-glossary.txt:
* <code>./txt-to-pot.sh gnc-glossary.txt > gnc-glossary.pot</code> will generate a new gnc-glossary.pot,
* run above ''msgmerge'' command for your XXXX.po and check it for the new msg,
* if successful, update all *.po files with:
 find *.po -exec /usr/bin/msgmerge -o '{}' '{}' gnc-glossary.pot \;
* check and translate the new string in your new glossary file.

=== Build a new .po file ===

If there is no .po file for your language, then you can start a new one. Start by 
 msginit -lLL[_CC]
where <tt>LL</tt> is your language and CC your region code, if there is already a different LL.po like e.g. ''pt'' and ''pt_BR''. 
: -i<path/to/>gnucash.pot is required, if you use a separate build dir,
: -l... is only required, if your target is different from your environments current language.
This will initialize the meta information with values from your user environment.
;Note: msginit  0.19.3 is querying an obsolete address of the translation project for language teams, but that doesn't matter.

If that does not work you can copy the file <tt>gnucash.pot</tt> into a work file named <tt>LL.po</tt> and just edit this file.

==== Adjust the header and special strings====

The top of the .po file should be edited somewhat.  The comments at the 
top of the file should be changed to be current:

 # Messages in Deutsch fuer GnuCash
 # Copyright (C) 1999 Free Software Foundation, Inc.
 # Jan-Uwe Finck <Jan-Uwe.Finck@bigfoot.de>, 1999.

Make sure that the header of your .po file contains an adjusted form, e.g. for slavian languages set nplurals=3, of this line:
 "Plural-Forms: nplurals=2; plural=n != 1;\n"

...and that you change the "Last-translator" string to your name.

The first lines as shown in the previous section will contain several '''capitalized entries'''. ''Replace all the words in capitals'' with something appropriate. In this case, you will be the first author of the translation, and also the 
* last translator of it. 
* CHARSET may be UTF8 for example, and 
* ENCODING is usually 8bit. 
Remove the `#, fuzzy' line once you have specified the items in capitals, because once this is done the header entry is no longer fuzzy. 

There is currently one '''special string''':

 #: ../src/gnome-utils/gnc-main-window.c:4389
 msgid "translator_credits"
 msgstr "Christian Stimming <christian@cstimming.de> et. al."

This will appear in <tt>Help->About->Credits->Translation</tt>. So you should enter your ''name'' or that of your team and an ''email'' address where users can contact you for typos and gifts.

==== Adjust configure.ac ====

Also include your language code into the ''NEW_LINGUAS variable'' in the '''configure.ac''' file ''in the top level folder'' of the source package: <SyntaxHighlight lang="sh">

dnl Set of available languages:
dnl managed at the Translation Project:
TP_LINGUAS="az ca cs da eu fa ja nl rw sk sr sv tr uk zh_CN"
dnl already marked as external at TP:
GC_LINGUAS="ar bg de el en_GB es fi fr gu he hi hu it kn ko lt lv mr nb ne pl pt pt_BR ro ru ta te ur vi zh_TW "
dnl New or unmarked: The release manager should announce them to TP 
dnl and when listed there move in the respective group above.
NEW_LINGUAS="as brx doi es_NI kok kok@latin ks mai mni mni@bengali"

ALL_LINGUAS="$TP_LINGUAS $GC_LINGUAS $NEW_LINGUAS"
</SyntaxHighlight>
As the name suggests, ''configure.ac'' is a file, which controls the configure process. So after changing it, you have to '''rerun [[#configure|configure]]'''. Some IDEs like [[Eclipse]] will do it automagical for you. 

So that <tt>LL.gmo</tt> file is generated in ./po directory during ''make install'', otherwise your translated language won't appear.

Continue with [[#Translating the .po file]].

=== Updating an existing .po file ===

Before you begin actual translation work, you should update the gnucash.pot 
file and use this to update your .po file.  This process will insure that 
you have the latest translatable strings.

It is important, to repeat this step e.g. after you asked a developer to change an insufficient string or you got an announcement about changed strings.

* If your repository is no fresh checkout, you should first [[#Update your repository]]:
 git pull --rebase
* Then in gnucash, a specific command ''at the '''top-level''' of the build tree'' (or source tree, if you do not use a separate build directory) will perform all necessary steps for this:
 make pot

'''Note:''' If make complains "<tt>make: *** No rule to make target `<path/to/missing-source-file>', needed by `gnucash.pot'.  Stop.</tt>", you should run
 make clean
and then retry "<code>make pot</code>". That can happen because we sometimes remove obsolete files.

Now go in the po directory:
 cd po

If your language file does ''not exist'', see the [[#Build a new .po file|previous section]] for creating a new language file.

If your language file ''already exists'', update it using the ''msgmerge'' program. This will move the old translations of unchanged strings in the new file:

 /usr/bin/msgmerge -o LL.new.po LL.po gnucash.pot
 mv LL.new.po LL.po

'''Note:''' If you had choosen a ''separate build directory'', e.g. <tt>build</tt>, adjust the path in above command:
 /usr/bin/msgmerge -o LL.new.po LL.po ../build/po/gnucash.pot
 mv LL.new.po LL.po

;Attention!: If there are more persons working on your language, you should now run <tt>git commit</tt> or ''create a patch'' "Merge updated po template in <ll>.po". This will contain only the "noise" from the updated pot file as usually many line numbers change.  Example of unchanged messages:

  #. Business options
 -#: ../src/app-utils/app-utils.scm:303
 -#: ../src/business/business-gnome/gncmod-business-gnome.c:117
 +#: ../src/app-utils/app-utils.scm:322
 +#: ../src/business/business-gnome/gncmod-business-gnome.c:119
  msgid "Business"
  msgstr "Geschäft"

Hiding your real changes in hundreds of such sections will make it really hard for your coworkers to find them.

=== Translating the .po file ===

Finally.  You are ready to do some translating!

The .po source files are plain text files.

==== Tools ====

Some ''plain text editors'' offer a specific ''syntax highlighting for .po file''s, but there are also specific tools you can use:
* ''Poedit'' ( get it here: http://www.poedit.net/download.php ) to finish the PO file edit and build.
* ''[https://poeditor.com/ POEditor]'' can be used online.
* ''KBabel'' is another recommended tool.
* ''Lokalize'' is the successor of KBabel in KDE4.
* ''Emacs'' has the po-mode to edit po files.
* ''[http://docs.translatehouse.org/projects/translate-toolkit/en/latest/index.html translate-toolkit]'' is a python based suite.
* GTranslator is another tool but we recommend not to use it because the version of 2006 doesn't support all of the interesting elements inside the po file.
(feel free to add more tools here)

==== Gettext source (.po) file format ====
A record in a po file has the following form:
<syntaxhighlight lang="po">white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgid previous-untranslated-string
msgid untranslated-string
msgstr translated-string
</syntaxhighlight>
*The ''white-space'' line is the record separator.
*In ''translator-comments'' you can put your own notes.
*The ''extracted-comments'' are notes from the programmers for you.
* One ore more ''reference''s tell you, where the message appears in the sources.
* The most important ''flags'' will be explained below.
* The ''msg*'' should explain themself above.

;Example:Here is an example of translating some text into German:

Before:<syntaxhighlight lang="po">
#: messages-i18n.c:11
msgid ""
"The GnuCash personal finance manager.\n"
"The GNU way to manage your money!"
msgstr ""
</syntaxhighlight>
After, the translation in the de.po file:
<syntaxhighlight lang="po">
#: messages-i18n.c:11
msgid ""
"The GnuCash personal finance manager.\n"
"The GNU way to manage your money!"
msgstr ""
"GnuCash: Ihr persoenlicher Finanzmanager.\n"
"Der GNU-Weg, ihr Geld zu verwalten!"
</syntaxhighlight>
You should read through every translation in the .po file at least once.  
If you translate a string that has the phrase "#, fuzzy" in the comments
above it, remove the word fuzzy.   A fuzzy translation means that there is no translation. The
computer took some guess about what the translation might be, but as long as it is marked "#, fuzzy", this guess will simply be ignored and this string will stay untranslated. A string marked as "fuzzy" means it will not be translated in the program.

After you finish translating, you should not have any "#, fuzzy" strings left. Remember, a string marked as "fuzzy" means it will not be translated in the program.

For example:
<syntaxhighlight lang="po">
#: messages-i18n.c:35
#, fuzzy, c-format
msgid ""
"There was an error writing the file\n"
"     %s\n"
"\n"
"%s"
msgstr ""
"Es gab einen Fehler beim Oeffnen der Datei. \n"
"     %s."
</syntaxhighlight>
You need to correct the translated string and remove the 'fuzzy' keyword, because only then the translation will actually appear in the program.  Remember, a string marked as "fuzzy" means it will not be translated in the program.
For example:
<syntaxhighlight lang="po">
#: messages-i18n.c:35
#, c-format
msgid ""
"There was an error writing the file\n"
"     %s\n"
"\n"
"%s"
msgstr ""
"Es gab einen Fehler beim Schreiben der Datei. \n"
"     %s."
</syntaxhighlight>
Notice that the comment "c-format" was ''not removed''.  That is correct, you 
should leave that.

When you see the comment "c-format", it means that the format codes in the 
translatable string are referring to C formatting codes.  So, '%s' means text, 
'%d' means an integer, etc...

==== Translate the strings ====

Each message to translate is then given in turn in the PO file. For example, an untranslated entry might be:

 #: lib/error.c:88
 msgid "Unknown system error"
 msgstr ""

The empty '''msgstr''' string has to be filled with the translation for the string shown after '''msgid'''. If you were a German speaker, say, the entry once translated might look like:

 #: lib/error.c:88
 msgid "Unknown system error"
 msgstr "Unbekannter Systemfehler"

You just produce a translation for all entries in the PO file, one after another, respecting the overall file format and the quoting needed for special characters, when needed. Observation and intuition may allow you to grasp what the format should be; the precise rules for PO files are given in the GNU gettext manual. The msgfmt program is helpful for pinpointing formatting errors.

===== Special characters and other tips =====
''Depending on the context'' a few characters have a special meaning and need some special treatment:
;"_" (underline): In ''menu and dialog entries'' the following character will become the '''accelerator''' or '''hotkey''', which can be used together with a superkey [ctrl] or [alt] to jump to the entry. So it should be unique in its context. You should control it by [[#Running GnuCash]] with your file after [[#Compile & Install]].
::''wrong:''
:::"do _this" # Hotkey: t
:::"do _that" #  Hotkey: t => unreachable 
::''right:''
::: "do th_is" # Hotkey: i
:::"do th_at" # Hotkey: a
::That is one of the reasons why you should run the program with your translation: to see duplicate accelerators.
::;Characters to avoid: 
:::Already used on buttons like in English: '''C'''lose, '''H'''elp. Others depend on the context.
:::Characters breaking the baseline like in latin script: '''j''','''p''','''q''','''y'''. At least in some fonts the underline becomes invisible - leaving the user clueless.
:;In the headers of exported files: here it is used to link multiple words to one identifier together. Example:
<pre>#: ../src/import-export/csv-exp/csv-tree-export.c:155
msgid "full_name"
msgstr "Vollständige_Bezeichnung"
</pre>

;"\" (backslash): It is the escape character in many programming languags. The following character has a special meaning like e.g.:
:;"\n" (New line): The most often used special character in our strings. If msgid contains "\n" keep the layout and add them to msgstr too - at the same places.
:Use <tt>"\\"</tt> to print a backslash.
;"%" (percent): In C based programming languages "%" marks the beginning of a '''format specifier''', e.g. "%d6" means insert the next variable here ''in decimal format with 6 digits''.
:* If no real format specifiers are in the string, [http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash&component=Translations file a bugreport] and tell the developers the location of the string (the lines above the msgid), where they should insert a comment containing '''<tt>xgettext:no-c-format</tt>''' before the gettect call.
::To continue with your work just remove the <tt>c-format</tt> flag from the <tt>#,</tt> comment line above. If no other flags are in the line, simply remove the line.
:* To output "%" if a string contains format specifiers, use "%%" in your string.
:;Reordering parameters: Assume a string <tt>"In %d cases the result will be %d."</tt>, but in your language you would prefer to write <tt>"%d will be the result in %d cases."</tt> Now you would get the wrong numbers.
::;Solution: Insert the ordinal number of the parameter, followed by "$" in the format specifier: <tt>"%2$d will be the result in %1$d cases."</tt>.

==== Check syntax and statistics of your .po file ====
 msgfmt -c --statistics LL.po
If that program reports one or more ''fatal errors'' for your language, you should review the criticized lines of your file. In a second run you might wish to see, where you forgot to add an [[#Special characters and other tips|accelerator]]:
 msgfmt -c --check-accelerators="_" --statistics LL.po
The users will love you if you fix this, too.

==== Current status ====
See [[Translation Status]] for the current status of the project with respect to translation contributions.

To see some over all statistics how many strings are translated, you can run
 for i in *.po; do echo -n "$i:"; msgfmt -c --statistics $i;done
in your po directory.

==== Priority ====
As you might have noticed, the po file for GnuCash is rather big by containing more than 4000 strings. It is somewhat helpful to look into different priorities for the different strings there. However, unfortunately the po file format doesn't enable any easy way for the GnuCash project to make the import strings differently from the less important ones. However, for a few files the developer team can give you some guidelines for the general priorities.

The ''source code location'' of a string gives you some hint about its priority. In particular, the following file suffixes or file locations imply a certain priority:
* '''High Priority:''' Strings from all '''*.glade.h''' files will appear in the GnuCash user interface (UI) somewhere for the user. This may imply a somewhat higher priority to those strings - however, some UI elements are rarely used, so the actual location of the .glade file has an influence as well, but there isn't an easy rule for that anymore.
:;Tip: If you wish to see the string from a *.glade.h file in it's context, but don't know, where it is hidden in gnucash, you can open the file <tt>gtkbuilder/*.glade</tt> with Gnomes interface builder [https://glade.gnome.org/ Glade]. 
* '''Low Priority:''' Strings from all '''*.schemas.h''' files will '''not''' appear in the gnucash UI. Instead, they are shown only inside the ''gconf-editor'' program when the user wants to set particular gconf keys of GnuCash. You can safely consider the .schemas.h strings with lower priority than the others.

Unfortunately, there is no such simple rule for strings from *.c files or the single large intl-scm/guile-string.c file. The strings from there may be of higher or lower priority, but this isn't easily visible. We can only recommend to start GnuCash on your own with your updated translation, and then check for strings which you see but are not yet translated. Those are for sure of high priority.

Two additional source code locations can be noted as low priority:
* Everything from the file ''src/bin/gnucash-bin.c'' is of '''low priority''' because those are the command line options when running gnucash with different options from the command line. This is a use case that is performed only by highly experienced users which are accustomed to using the English-language command line commands. Therefore, translations here are of lower priority.
* Everything from the folder ''src/tax'' or from the intl-scm/guile-string.c file with a comment indicating some file in ''src/reports/locale-specific'' is related to tax preparation in the U.S. or in Germany. Hence, those strings are uninteresting for anyone living in different countries, and you can safely consider those with very '''low priority'''.

==== Disambiguation Prefix ====
At some places, GnuCash uses "disambiguation prefixes" in translatable strings. Here is an old explanation:
https://lists.gnucash.org/pipermail/gnucash-devel/2005-October/014236.html ; more explanation is also here: http://live.gnome.org/GnomeI18nDeveloperTips . 

@Developers: In the normal source code of a gtk-based program, this feature is available by simply using the [http://www.gtk.org/api/2.6/glib/glib-I18N.html#Q-:CAPS Q_( )] macro instead of the _( ) macro.

This would be used e.g. as follows
 /* Translators: This string has a disambiguation prefix */
 func(Q_("Noun|Transfer"));
where the string that shows up in the GUI is simply "Transfer", but the translators need the prefix to be able to choose the correct translation of the noun vs. the verb.

In the latest gettext versions, this disambiguation is solved in yet another way by introducing an additional "context string" in addition to the translatable string, see below. As this is still a relatively new feature, we don't use this in GnuCash yet.

===== Context by Particular Gettext =====

A more recent method is "particular gettext" pgettext(). 

Example:
 pgettext("account status: not cleared", "n")
would result in a msgid like:
 #: src/app-utils/gnc-ui-util.c:656
 msgctxt "account status: not cleared"
 msgid "n"
 msgstr ""

See [http://www.gnu.org/software/hello/manual/gettext/Contexts.html Gettext Manual: Contexts] for details.

=== Testing and submitting your translations ===

You must check that your new translations are programatically correct (ie: 
that there are no unclosed quotes, etc).  To do this, use the msgfmt program

 msgfmt -c --statistics LL.po

Above call will report most important errors in your .po file and ''must not fail'', while the call below
 msgfmt -c --check-accelerators="_" --statistics LL.po
whill additionally check if you missed some keyboard accellerators aka hotkeys. But this call ''formally will always fail'' as there is at least 1 string, where the underline is no accelerator marker: <code>msgid "translator_credits"</code> from [[#Adjust the header and special strings]]. So just eleminate the other warnings and ignore that about "translator_credits".

;Note for developers: Another python based tool is '''i18nspector''' - checking tool for gettext POT, PO and MO files. It is stricter and shows also warnings about expected entries which our .pot file is currently missing. That can be discussed e.g. in [[#Background]].

If you want to see your translations within a running version of gnucash,
simply place your .po file in the po/ directory of your local gnucash repository (which
you have previously installed) and from within the po/ directory type (you
may need to be root to do this):

 make install

Now you can run gnucash with your new translations:

 LANG=XXXX /opt/gnucash-git/bin/gnucash

To review the schema strings you can use
:;since 2.6: dconf-editor
:;until 2.4: gconf-editor.


==== Alternative Way with Poedit ====

If you use Poedit while working on .po file, you would notice that it saves file in .mo format, the very format that GnuCash uses itself. So one would just need to copy this LL.mo file into appropriate subdirectory under /opt/gnucash-git:
  cp LL.mo /opt/gnucash-git/share/locale/LL/LC_MESSAGES/gnucash.mo

The only thing that needs to be changed here is LL which stands for your country code (ka Georgian, de German etc). The rest is as in above method:
 LANG=XXXX /opt/gnucash-git/bin/gnucash

=== Submitting ===
When you are happy with the new translation file, create a gzipped version
of it:
 gzip XXXX.po
, do the same with your [[#The glossary file]] and follow [[#Submitting your work direct to GnuCash]].

Alternatively, you could submit the finished translation via the GNU Translation Project. See the instructions on http://translationproject.org/ and the first section of this document about how to do that.

See [[Translation Status]] for the current status of the project with respect to translation contributions.

See also http://lists.gnucash.org/pipermail/gnucash-devel/2009-January/024700.html [FIXME: obsolete?]

==== Committers ====
* Check in which branch the translation should be submitted: [[Translation_Status]]
* Did you get [[#The glossary file]], too?
* [[#Check_syntax_and_statistics_of_your_.po_file]]!
* If the language is ''new''
** [[#Adjust_configure.ac]] already done?
** and not handled by the [[#GNU Translation Project]], they need a '''note about the external handling'''. Else it can happen e.g. as of 2015-03  http://translationproject.org/team/ar.html shows:
 gnucash 	2.6.5 	0 / 4628
::If you there click on 2.5.6 you will get a fresh gnucash-2.6.5.pot, while we have already an ar.po with 2031 translated and 4 fuzzy messages. By contrast on the as external marked http://translationproject.org/team/de.html, you see:
 gnucash 	2.6.5 	unknown 	external
::and will not get a new pot file.
::But we can bundle this notes with the release announcement, if you add the language to [[Release Process#TP Status changes]].
* On committing add the name and email address of the last translator from the file as author, e.g.
 git commit --author="Lieutenant Worf <lt.worf@gmail.com>" --message="Update of tlh.po"
* If you check in a new language, remove a language or see the status of the language changes from partial to (almost) complete, update the numbers in ''<sect2 id="oview-featuresintl2">'' in file '''guide/C/ch_oview.xml''' of ''gnucash-docs''.

=== Problems===

==== intl/Makefile is already registered ====
When you see this error message during autogen.sh run:

 configure.ac:1219: error: `intl/Makefile' is already registered with
 AC_CONFIG_FILES.
 autoconf/status.m4:844: AC_CONFIG_FILES is expanded from...
 configure.ac:1219: the top level
 autom4te: /usr/bin/m4 failed with exit status: 1
 autoheader: /usr/bin/autom4te failed with exit status: 1
 **Error**: autoheader failed.

Then you need to revert the configure.ac script to the original form that is in git:
 git checkout configure.ac

==== Gtk-CRITICAL messages ====
'''Note:''' Fixing this problem is quite difficult. We keep the explanation here in case some developers need it in the future, but if you have no idea what we are talking about in the next sentences, you should rather ignore these Gtk-CRITICAL messages and our explanation here!

If you see any "Gtk-CRITICAL" messages while running gnucash, it is probably
because you translated a string differently than how it exists in some other
gnome library.  You must discover which string you translated differently, and
change the translation to exactly match that of the gnome libraries.

To do this, you need to run gnucash under gdb:

 LANG=XXXX /opt/gnucash-git/bin/gnucash-env gdb /usr/bin/guile

Then, from within gdb, issue:
 run -e main -s /opt/gnucash-git/libexec/gnucash/overrides/gnucash --g-fatal-warnings

Eventually, gnucash should crash (because of the --g-fatal-warnings 
directive), when it does, issue from within gdb:

 backtrace

You should see some output that looks like this:

 #0  0xffffe002 in ?? ()
 #1  0x42028a73 in abort () from /lib/tls/libc.so.6
 #2  0x4019d3d8 in g_logv () from /usr/lib/libglib-1.2.so.0
 #3  0x4019d414 in g_log () from /usr/lib/libglib-1.2.so.0
 #4  0x40500fdd in gtk_type_check_object_cast () from 
 /usr/lib/libgtk-1.2.so.0
 #5  0x407292e5 in gnc_mdi_tweak_menus (mc=0x825adb0) at gnc-mdi-utils.c:574
 #6  0x40729d13 in gnc_mdi_child_changed_cb (mdi=0x8266fd8, prev_child=0x0,
      data=0x8265fd8) at gnc-mdi-utils.c:861

Notice position #5 which has "gnc_mdi_tweak_menus at 
gnc-mdi-utils.c:574"?  Open that source file and find line 574:

 573:  widget = gnc_mdi_child_find_menu_item(mc, "_View/_Toolbar");
 574:  gtk_signal_handler_block_by_data(GTK_OBJECT(widget), info);

So, the problem is with the translation of "_View/_Toolbar".  The "/" is a 
menu seperator, so you now know that the problem is with either the 
translation of "_View" or "_Toolbar".  By switching to an English gnucash (LANG=C) 
and looking through your .po file, you should be able to find out the problem.
Change the offending translation to whatever you see in the gnucash app.
Remember that the translations must contain the proper underscores.

==== Watch File accesses ====
To follow gnucash as it access files, 
 strace /opt/gnucash-git/bin/gnucash

=== Thank You ===
Thanks so very much to all the translators for their hard effort and
excellent work.

== How to translate the Windows Installer==

Follow the instructions in the [https://lists.gnucash.org/pipermail/gnucash-devel/2009-January/024535.html this thread].

== Check doc/README-* ==

The following filepatterns in doc/ are of interest:
* README-<language>
* README-<LL>.win32-bin.txt

This plain text files are often forgotten and become easily outdated. But if gnucash-doc is not installed or yelp not working, they are the only documentation, which the user can find in your language on her computer.

'''Q:''' Shouldn't it be possible by some make-magic, to adjust current-, last-stable-, next-stable- release and release-date - e.g. like target gnucash.1 in makefile? --[[User:Fell|Fell]] 20:21, 16 September 2010 (UTC)

== Translating the GnuCash Guide and Help==

This section describes the actions needed to translate the manuals. There are currently 2 parts:
* ''Tutorial and Concept Guide'': This is an introduction in the basic principles of double entry accounting and their application in GnuCash. This text is really useful for new users. 
* '''Help''': This is the context sensitive help system. 

If you are interested in translating these documents, please decide whether you want ''only'' to translate the existing text or whether you want also to improve and cross-check the text with the actual status in the program in your language. It is less effort only to translate the text, but you also run into the risk of doing unnecessary work if you translate explanations which are no longer correct. It might be more effort to create a new text in your language, using the English text only as an inspiration, but it will surely lead to more useable and more helpful documentation. We, the programmers, encourage you to do the latter and create a new text in your language. As you are the one doing the work, the decision is up to you.

Both documents consist of 
* text files in an XML format called [http://en.wikipedia.org/wiki/DocBook DocBook], where the complete document is split into a collection of xml files by chapter, and
* pictures: Those are png files in the subdirectory figures/. The xml files will contain links to the png files where they should appear in the text.
At the beginning you might wish to concentrate on the text. If desired, you could link the english pictures from <tt>C/figures</tt>.

You can find an introduction to DocBook in [http://docbook.org/tdg51/en/html/ch02.html Creating DocBook Documents].

Please use a ''unified terminology'': The translator of the program messages should have created [[#The glossary file]] for the translations of the key wordings in the program. Please make sure to use the same terms in the documents, too.

You can check the [http://code.gnucash.org/docs/ nightly builds] - in particular after your updates were committed.

=== Prerequisites ===

==== Linux ====

In addition to the software for running autogen.sh, the following additional software is needed for the development on Linux. From the [https://github.com/Gnucash/gnucash-docs/blob/master/README gnucash-docs/README] file as of 2016-01-23:

:* libxml2
:* libxslt [Debian packed the required xsltproc in a separate package, 
::          which depends on libxslt]
:* docbook-xsl
:* rarian or
:: scrollkeeper >=0.3.4 (its ancestor)
:* yelp (for viewing)

:Optional:
::* gnome-doc-utils (contains <tt>xml2po</tt> for the use of po editors like in the it translation)

:Additional Requirements for Generating PDF:

:* Apache fop  >= 0.95

:For the Japanese PDF, Japanese fonts are included. If you want to use
:other Japanese fonts you can use the --with-japanese-fonts-dir,
:--with-japanese-mincho-ttf, and --with-japanese-gothic-ttf configure
:options to select them. fop's TTFReader can't, as of version 1.1
:anyway, handle OpenType fonts.

:Additional Requirements for Generating Mobipocket:

:* Calibre (http://www.calibre-ebook.com/)


'''Note for wiki editors:''' Keep above section in sync with [https://github.com/Gnucash/gnucash-docs/blob/master/README gnucash-docs/README]

==== Other Operating Systems ====

Wm says the section below is being edited and not yet complete, see the thread "Help with help" in gnucash-devel for more info
----

===== MacOSX =====

At present we do not know of a suitable DocBook file toolset for ''MacOSX'' though a *nix on Mac approach may / should work.  We encourage solutions so if someone could document this we would be grateful [Wm: aside is this redundant? Don't most modern Macs include *nix so instructions similar to those I have provided for Win might apply?]

===== Windows =====

One way of being able to edit and produce DocBook files on ''Windows'' is to use the *nix instructions under cygwin.  Instructions for obtaining a suitable toolset follow

*Get cygwin by going to http://www.cygwin.com and pressing the link for the setup-*.exe file suited to your system
*save it, virus scan it, etc. as you see fit then run it
*type "libxslt" into the search box
*expand Libs and press Skip so that it shows a version for all 3 GNOME XSLT Library options, you want the most recent which it will offer by default, cygwin will work out the gndependencies
*you may follow similar steps to obtain git, i.e. type "git" into the search box, expand and tick the obvious candidates
*Note: because these are *nix type text based utilities you are downloading hundreds of kiloBytes not megaBytes; relax, this isn't Windows Update, a few extra progs won't kill your system, promise
*click next at the bottom rhs and let cygwin do its stuff; this may take some time depending on connection speeds at both ends
*Aside: if you get a msg about "Package: Unknown package / inetutils.sh exit code 1" you may ignore it, after reading the full blurb, of course, my advice is not to try and track it down unless you have a lot of spare time on your hands
*When it is done fire up cygwin and do stuff as per the *nix instructions

Further details:

*don't look for
:*yelp (the viewer)
*on cygwin: it isn't there; it is an old prog (last updated in 2007, I think
:: wrong, see http://ftp.gnome.org/pub/GNOME/sources/yelp/. --[[User:Fell|Fell]] 17:21, 26 October 2013 (EDT)
:) and should probably not be regarded as current though it may be useful if you have it on another OS
: [Wm: 
::* I wonder how many current *nix users have it?
::: AFAIK it is still part of the GNOME desktop: [https://www.google.de/search?q=yelp+gnome google search for yelp+gnome] --[[User:Fell|Fell]] 17:21, 26 October 2013 (EDT)
: Should ref to yelp be made less prominent?
:: It is the only way I know to get some context sensitive help from inside GnuCash. --[[User:Fell|Fell]] 17:21, 26 October 2013 (EDT) 
: ]

----
Wm says the section above is being edited and not yet complete, see the thread "Help with help" in gnucash-devel for more info

===== Java (all OS) =====

[[Eclipse]] has 
* several Git plugins,
* a C Development Tool with autotools support,
* a feature rich, builtin XML editor and a few plugins like XML WYSIWYG editors
or in other words, all what is needed here, available.

=== The Procedure ===

First, you have to download the most recent version of the gnucash-docs package. This is done as follows:

# Checkout the documentation in a directory ''gnucash-docs'':
#: <code>git clone <nowiki>https://github.com/Gnucash/gnucash-docs</nowiki> -b maint gnucash-docs</code>
# Create your working branch. If you plan to use pull requests, you should use unique names like ''guide-LL-chapter-x-part-n'' instead of working-branch.
#: <code>git checkout -b working-branch</code>
# Create a new directory (if it doesn't already exist) in guide/<locale> where <locale> is of the form <language>[_<region>] e.g. es, en_GB, or pt_PT. See [[#Naming Conventions]].
#:See [[Locale_Settings#IETF_language_tags]] for details.
#:If your translation is the first for your language do not add a region code. So also other regions benefit from your translation.
#:And copy the files from guide/C into this directory:
#: <code>cp -r guide/C guide/LL</code>
# Add the directory you created to [gnucash-docs/]'''configure.ac''' (as a new line ''guide/<language>[_<region>]/Makefile'' under AC_OUTPUT) and [gnucash-docs/]guide/Makefile.am (at the end of SUBDIRS).
# Notify git about the new directory and files. "*" is quoted by "\".
#: <code>git add guide/LL/\*.\*</code>
# Now the real work: 
## Edit '''all the xml files''' (see [[#DocBook xml editors]] below for suitable editor programs) and translate them into your language.
##: In the event the english documents get updated, it might be useful to have a comment in the header of each chapter in  the form:
##: <pre><!-- Translation based on maint/master as of 2014-01-01 10:00 UTC --></pre>
##: Use the same terminoloy as in [[#The_glossary_file]]. If you did not [[#Get_the_source_from_Git]], you can simply download your languages .po file from the [https://github.com/Gnucash/gnucash/tree/maint/po/glossary glossary directory at GitHub].
## Adjust  '''<tt>gnucash-{guide|help}-<lang>.omf</tt>'''. This file follows [http://www.ibiblio.org/osrt/omf/ Open Metadata Framework] (OMF), a subset of the [http://dublincore.org/  Dublin Core] description for metadata. See [http://scrollkeeper.sourceforge.net/documentation/writing_scrollkeeper_omf_files/index.html Writing ScrollKeeper OMF Files] for details like mandatory standard elements. Without this file your document will not show up in ''yelp''s index page. At some point in the future we might extract this data automaticly from the docs using  [[Gnome Doc Utils]].
##: Currently it is also necessary to replace in <tt>{guide|help}/<lang>/Makefile.am</tt> the "C" in both occurrences of <tt>$(docname)-C.omf</tt> by <lang>.
## There are some general headers, which do not appear in the xml-files in your locale directory. But they can be translated by adding ''a section in '''xsl/l10n.xml'''''. Obey the comment at the beginning. If you use non-ASCII characters, you should run <code>recode -d <input_encoding>..h0 l10n.xml</code>, where input_encoding might be u8 for UTF8, to get them right encoded.
## In addition to the text, you need to ''recreate the image files in '''guide/C/figures''''' so that they are appropriate to your language. For details (size, style,...) see [[Documentation_Update_Instructions#Images and screenshots]].
### Most of them are '''screenshots''' of a gnucash session - save them as png files because this will use a lossless compression. In theory some of the files in gnucash/doc/examples could be a starting point therefor, but they are currently - 2010-09-17 - broken.
### A few figures are in '''scalable vector graphic''' (svg) format. Here you can edit the files e.g. in ''Libre/OpenOffice'' and translate the strings and adjust the size.
## Watch out: The documentation itself is ''probably outdated in many places'', as it has been written for the 1.8.0 version of gnucash. You can watch the current progress in [[Concept_Guide#Ongoing_work]]. If you encounter any description that is wrong for the current version of gnucash, do not hesitate to ignore the english original text and instead describe the situation of the current version of gnucash in your translation. It would be even better if you have the time to change the english original text as well, or at least ''file a bug against it'', but even if you can't do that, feel free to describe the actual state of gnucash in your translation and simply ignore the original english text.
##: If you file a patch against the english text, you can also file a patch, which adds your name and email address to AUTHORS, so you will become famous. ;-) Ask to apply this latter patch also against gnucash/DOCUMENTERS because both files should have the same content. More details about editing the english text can be found in the [[Documentation Update Instructions]]. 
# Test your xml files for syntax errors by running ''xmllint'' on the '''main file''' ''gnucash-{guide|help}.xml'', e.g.:
#: <code>xmllint --valid --noout gnucash-guide.xml</code>
#: The program ''xmllint'' is part of the package '''libxml'''.
#: '''Tip:''' Some ''xml aware editors'' have a menu entry like ''validate'' to run this test. 
# Optional: test your work with yelp - there are autotools files, to support you:
## After you copied the directory, change to the 'root' of the gnucash-docs package and run once 
##: <code>./autogen.sh</code>.
## If you want to change some default values like installation paths, run 
##: <code>./configure --help</code>,
##: to see the available options.
## There are 2 variants of configuration: with or without a separate build directory. The downside of a separate build dir is you will have to <tt>cd</tt> to the builddir to run the make commands and then again <tt>cd</tt> to your sources to edit them again - at least if you work only with command line tools. The benefit is your source directory will not be cluttered. In most cases developers prefer to use a separate build directory.
### '''with build directory''' run
###: <code>md build</code> ## only once required
###: <code>cd build</code> ## every time required, you want to run make or configure
###: <code>../configure</code> with your desired options,
### '''without build directory''' just run
###: <code>./configure</code> with your desired options.
##: '''Tip''' for ''Windows'' and ''MacOSX'', which have no Yelp: use <tt>--disable-scrollkeeper</tt>
## After your editing of the files, run
##: <code>make</code>
##: for some additional processing. The default target are xml files for yelp. Other targets like html, pdf, ... must be given explicit:
##: <code>make html</code>
## To check the syntax of your files, run
##: <code>make check</code>
##: This will run the <code>xmllint</code> command above over the full diretory structure.
## If you had choosen something with "$HOME" as prefix in your configuration, run
##: <code>make install</code>,
##: otherwise run
##: <code>sudo make install</code>.
## Run
##: <code>yelp <path/filename></code>
##: with the path, to where you installed the files. This path consists of <tt>$PREFIX/share/gnome/help/gnucash-guide/LL/gnucash-guide.xml</tt> or gnucash-help.xml.
##:;Tip: <code>export XDG_DATA_DIRS=/home/<yourname>/<your-install-dir>/gnucash-docs/share:${XDG_DATA_DIRS}:/usr/local/share:/usr/share</code>
##:: will tell yelp the path to your version.
## Repeat steps 4-7 until everything is right.
# Update the branches of your local repo often:
#:<code> git checkout maint              # switch to maint</code>
#:<code> git pull --rebase               # update it</code>
#:<code> git rebase maint working-branch # update working-branch</code>
#:<code> git checkout working-branch     # switch back to working-branch</code>
# Follow [[#Submitting your work direct to GnuCash]].

To translate the help files, repeat steps 2-10 but replace the "guide"
directory with "help".

'''Committers:''' If it builds fine, add the directory changes from 2. also to <tt>gnucash/maint/packaging/win32/install-impl.sh</tt> and merge the change to master, if required.

=== DocBook xml editors ===

For editing these DocBook xml files, various editors can be used: http://en.wikipedia.org/wiki/DocBook might contain pointers to some, or also http://www.tldp.org/LDP/LDP-Author-Guide/html/tools-edit.html . Some developers use [[Eclipse]].

People have said that AbiWord and OpenOffice / LibreOffice have support for DocBook available, in which case you could directly edit gnucash's xml files with those. However, those editors will probably not work with the current multi-file setup where each chapter is in a separate XML file and the main XML file contains points to the chapters' files. As a workaround, you can copy the relevant parts of the main XML file into the chapter's file by a plain text editor so that it "looks like" one single DocBook document. This can be opened with OpenOffice/LibreOffice and edited as normal. After that, the added parts from the main file need to be removed again, and then you have the edited chapter text.

=== Using po editors ===

Some translators are more familiar with using po file editors like poedit, Kbabel, Gtranslator etc. For those people, it is possible to convert the content of the help documents (the DocBook XML files) into po files, translate the messages in the po file, and convert the result back into xml. This section describes how to use this approach for the gnucash help documents.

;The downside of this approach: It will be much harder for the documenters to fix e.g. broken links in times where you are inactive.

In order to use po files you have first to convert xml files to po files, translate them and then convert back to xml.

First you have to install a fresh version of gnome-doc-utils. For example in a Fedora 13 system
 <code> yum install gnome-doc-utils</code>.

#Do the conversion with the following commands (xx is your language code, example: el for Greek): 
#: <code>xml2po -o helpfile.xml.pot helpfile.xml</code>
#: <code>mv helpfile.xml.pot helpfile.xml.xx.po</code>
#Translate helpfile.xml.xx.po using your favorite po editor.
#Convert back to xml:
#: <code>xml2po -e -p helpfile.xml.xx.po -o xx_helpfile.xml helpfile.xml</code>
#Test your translated xml file as mention above:
#: <code>xmllint --valid --noout xx.helpfile.xml</code>
#Remove xx from xx_helpfile.xml and you are ready to commit it in your language help directory

=== Workaround for the broken OpenSuse help system ===

As in OpenSuse 10.x and 11.x the help system is broken, there is a workaround, to review the result of your work. Locate gnucash-guide.xml in your system, probably /usr/local/share/gnome/help/gnucash/C. Then from that directory do 

 xmlto -o /path-to-where-you-want-to-store-docs/ html gnucash-guide.xml

which will make an html copy of the docs.

Copy over the 'figures' directory with contents to your html directory above
and set a bookmark in browser to the index.html so that you get the docs
any time you need them. The context sensitive facility is lost, but for
general reading it works.[https://lists.gnucash.org/pipermail/gnucash-user/2008-September/026699.html]

=== GnuCash Maintainer Tasks ===
For new languages the core developers have some additional tasks:

==== New Script ====
Check <code>make pdf</code>! Do we need additional TTFs?

==== First Nightly ====
Ask the webmaster of code.gnucash.org to create the new directory.

==== First Release ====
Adjust htdocs ...

== How to translate the files containing the new account hierarchies==

This section describes the actions needed to translate the files
containing the new account hierarchies.

=== Preliminary Considerations ===
:However, please take a moment to think about the intention of the account hierarchy templates. The intention of those files is much more language-related than any other of the files inside gnucash. A string-by-string translation is not the best thing to do here. Instead, you can and should find out an actual recommended account structure which makes sense in your language, and implement that one in your language. By this, I mean several of the english accounts make sense only in the U.S., but probably not in other countries. Hence, your translated account template should not contain them. Also, you can add additional parts of the account templates for your language as well, if the users are likely to need it. 

:For example, in the U.S., users are likely to own a car, and for this reason there is an account structure template for "Car". If in another hypothetical country users are likely to own, say, a spaceship instead of a car, you should remove the "Car" template and instead create a new account structure that represents all accounts related to the ownership of a spaceship, and offer this as additional "Spaceship" template.

:In other words, you should feel free to create a completely new account template structure that is most suited to your language. The english-language templates are just a proposal, but will need further adaption and not a string-by-string translation.

Having said that, here is how you would start for a direct translation of the English templates:

In this section always replace <tt><locale></tt> with your [[#Naming Convention|language code]] and ''optional'' your region code, if there are multiple countries with the same language and your templates are fitting only to one of them.

=== Prerequisite ===
* If not done before, [[#Get the source from Git]].

=== Initialize accounts/<locale> ===
* If it does not already exists, execute the following steps to initialize your <tt>accounts/<locale></tt> directory:
# Create a new directory  <tt>accounts/<locale></tt>.
# Copy the <tt>acctchrt_*</tt> files from <tt>accounts/C</tt> to <tt>accounts/<locale></tt>
# Do not change any xml tags. 
# In the directory <tt>accounts/</tt>, change the file Makefile.am and add your <locale> to the only line in that file.
# Add the path of your Makefile.am to <tt>AC_CONFIG_FILES</tt> in <tt>configure.ac</tt> in the toplevel directory of the project.

=== Localize the Account Charts ===
'''Tip:''' <tt>C/acctchrt_full.gnucash-xea</tt> is a helper file. Because we prefer modularization it usually is not part of the distribution. It contains the full tree of the ''personal en_US accounts''. The other <tt>acctchrt_*.gnucash-xea</tt> files contain single branches of that. So after translating it you can copy&paste the respective parts in the other files to ensure consistency between them.

If you modularize the templates you should start with <tt>acctchrt_common.gnucash-xea</tt> - it is the most basic.

For each ''desired'' <tt>acctchrt_*</tt> file in that directory:
# Change the <tt>gnc-act:title</tt>, <tt>gnc-act:short-description</tt>, and <tt>gnc-act:long-description</tt> to contain appropriately translated text. Do not add any newlines in the long description except at the end and begining of the string.
# For each <tt>gnc:account</tt> in the file translate the <tt>act:name</tt>, and <tt>act:description</tt> fields.  Please do not translate any other fields.
# To avoid typos, run the [[AccountHierarchyTemplate#Syntax Check]].
# New files to be shown to the user must be added to the <tt>account_DATA</tt> section,
#:helper files like ''acctchrt_full.gnucash-xea'' to <tt>EXTRA_DIST</tt> in <tt>Makefile.am</tt>.

'''Note again:''' You absolutely don't need to translate all of the files from
<tt>accounts/C</tt>.  A subset of those are fine as well. Probably several of
them will not apply to your local legislative/economic system anyway.
For a really customized account hierarchy you might better create a
new account hierarchy file in GnuCash, and then, by hand-editing the
xml code, split it up into several files and cut&paste the appropriate
tags from the accounts/C/acctchrt_* files.

If you wish to add new accounts manually, you will need some additional guids, those funny random numbers. To get them you can use:
 gnucash-make-guids
or, if that command does not exist,
 uuidgen | sed -e 's/-//g'

[[AccountHierarchyTemplate]] describes, how to create new templates e.g. for business purpose according local rules.

=== Test your Work ===
To test your work under real conditions, you should finally [[#Compile_.26_Install|Compile & Install]] it. But before you need an adjusted '''Makefile.am''' in your accounts/<locale> directory. If none exists, copy that from <tt>accounts/c</tt> and adjust it:
* 1. Line (accountdir): adjust the locale.
* If you removed accountcharts, remove their line from <tt>account_DATA</tt>,
* if you added new files, insert lines with their names and "\" (the line continuation symbol).

== How to create localized Income Tax Tables ==
;Note: This section is under developement and mostly untested!

As of the beginning of 2015 there is an nice US tax module with a report and export in TXF format.
Additional there is a small de_DE derivate for the monthly VAT declaration. you can compare them to see, how you can tweak them to get something else.

=== Tax Table ===
From https://github.com/Gnucash/gnucash/blob/maint/src/tax/us get the files
* txf.scm - the tables, and
* txf-help.scm - the descriptive help strings for each TXF code. This is also used to get a table in gnucash-docs/help/

They have relative simple table structures:
 (define txf-tax-entity-types 
contains a list of forms for different entities (person, company,...).
 (define txf-income-categories ...
 (define txf-expense-categories ...
contain for each of the above lists the entries. If you compare this file with the respective *_DE file, you can see an example localization with additional categories:
 (define txf-asset-categories ...
 (define txf-liab-eq-categories ...
It should be possible to adapt the lists for your tax forms. Then you might submit them to an enhancement request in buzilla, product:Gnucash, component:TXF Export.

=== Report and Export===
Probably you need to have other export reports. That are in
https://github.com/Gnucash/gnucash/tree/maint/src/report/locale-specific/us like
* txf-export.scm
* us.scm is unused
Here you might probably need some help from a programmer.

== How to translate the website ==
* Get a checkout of https://github.com/Gnucash/gnucash-htdocs
* Run the command <pre>make pot</pre>
* Then depending on whether or not a translation for you language exists already (complete or not):
*;Existing translation:<br>Run the command <pre>msgmerge po/LL.po po/gnucash-htdocs.pot -o po/LL.po</pre> where LL is your language code, see [[#Naming Convention]] above.
*:;Alternative: <pre>make msgmerge</pre> will update ''all'' .po files
*;New translation:<br> In the po directory run <pre>msginit</pre> If that fails copy the newly created file po/gnucash-htdocs.pot to po/LL.po, where LL is your language code, see [[#Build a new .po file]] earlier.
* Translate the po/LL.po file as described in [[#Translating the .po file]].
*;Priority:
::;High: Startpage: {index|externals/*}.phtml
::;Low: sizing.phtml (outdated) search/templates/NMZ.* (unused)
::;Medium: the rest depends on you.
* Run <pre>msgfmt -c --statistics po/LL.po</pre> to see your success.
* Optionally run <pre>recode -d <input_encoding>..h0 po/LL.po</pre> to get special characters HTML quoted.
* Send the LL.po to gnucash-devel; the maintainers will commit this to git and add the appropriate Makefile rules upon the first git commit.

;Note about OS: These instructions are written for linux. They will probably work on other unix-like systems as well, but not on Windows. On Windows you may be able to do this if you set up a linux-like environment (with cygwin or MinGW[-w64]), but that's untested so far.

===Maintainers Task===
To make the changes visible, you will have to 
* run
 msgfmt -c --statistics po/<ll>.po -o locale/<ll>/LC_MESSAGES/gnucash-htdocs.mo
: or to compile ''all'' translations
 make mos
* and include the mo file(s) in your commit.

== Tips for Developers ==

This section collects some notes for developers/programmers on how to correctly prepare their code for translations.

=== How to make strings in code translatable ===

Strings in Glade files are marked for translations by the <tt>(_ )</tt> functions.

Normally, strings in C code just need to be enclosed with the <tt>_( )</tt> function (well, actually it is a macro expanding into a function, but this is usually just an implementation detail). For example,
 func("A translatable string!");
should instead be written as
 func(_("A translatable string!"));

However, it is important to keep in mind that <tt>_( )</tt> is a function; this means that in certain situations it cannot be used. For example,
 gchar* array_of_strings[] = {_("first string"), _("second string"), _("third string")};
would cause a compiler error. Instead, these strings should be wrapped with the <tt>N_( )</tt> macro, which is declared as <code>#define N_(String) gettext_noop(String)</code>. Then, whenever one of the strings is actually ''used'' (as opposed to ''declared''), it should be wrapped with the <tt>_( )</tt> function again:
 gchar* array_of_strings[] = {N_("first string"), N_("second string"), N_("third string")};
 func(_(array_of_strings[0]));

See also: [[Translation#Disambiguation_prefix | Disambiguation prefix]]

==== Plural Forms ====

Not all languages have the same simple kind of plural forms as english. See [http://www.gnu.org/s/hello/manual/gettext/Plural-forms.html gettexts Plural-forms] for details.

==== Empty Strings ====
There is no need, to mark an empty strings as translatable. The gettext tools use the empty string for their message catalog header. So it will confuse translators to have your preceding comment in the header of their .po file.

=== How to give the translators a clue ===

Sometimes it is useful to give the translators some additional information about the meaning of a string. To achieve this effect, you can insert a section of comment lines ''direct'' before the related string, where the first comment starts with "Translators:". There must not be any control statement between comment and string.

Example: <SyntaxHighLight lang='c'>
 /* Translators: the following string deals about:
  * The Answer to Life, the Universe and Everything
  * Source:
  * http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy */
 func(_("42")); </SyntaxHighLight>


In the pot and po files, this comment will show up as follows:
<SyntaxHighLight lang='po'>
#. Translators: the following string deals about:
#. The Answer to Life, the Universe and Everything
#. Source:
#. http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy
#: foo/bar.c:123
msgid "42"
msgstr "" </SyntaxHighLight>


'''Note:''' An empty comment line will end the process. If the string " Source:" were missing, the URL were not part of the output.

While this feature seems to work fine in C sources, it seems not to work in the scm files. Any suggestions, to fix this are welcome.

==== In SCM files ====
If the first expression has a translatable string and the file has a long header comment, split the line before the string and insert a translator comment. Otherwise the POT file will be flooded with file headers.
Example:<SyntaxHighLight lang='scheme'>
;; Boston, MA  02110-1301,  USA       gnu@gnu.org
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


(define GNC_COMMODITY_NS_CURRENCY
;; Translators: Namespaces of commodities
   (gettext "CURRENCY"))
</SyntaxHighLight>

==== In glade files ====

In glade 3.16, using the edit button for a label, one can enter translatable, translation context and comment.
From [https://bugs.launchpad.net/intltool/+bug/705420 intltool fails to extract comments from glade-type files when not last attributes]:
<SyntaxHighLight lang='xml'><property name="label" translatable="yes" context="infinitive" comments="my comment"></SyntaxHighLight> should work.

==== Introducing new terms ====
If you introduce new terms which are more than once used, you should include them to [[#The_glossary_file]]. The instruction is in [[#Terms missing or inadequate in the glossary file]].

=== Further Reading ===

If you want to read more about this topic, [http://live.gnome.org/GnomeI18nDeveloperTips GnomeI18nDeveloperTips] might be a good starting point. 

Follow the rules of the [https://developer.gnome.org/hig/stable/ Gnome Human Interface Guide] like [https://developer.gnome.org/hig/stable/writing-style.html Writing style] and [https://developer.gnome.org/hig/stable/typography.html Typography].

More technical and historical details can be found in [http://www.gnu.org/software/gettext/manual/gettext.html#Programmers The Programmer’s View of the Gettext Manual].

== Background ==
This section was started to get some overview, '''work in progress!'''
For details see the [http://www.gnu.org/software/gettext/manual/gettext.html GetText Manual].

=== Packages ===
In our build process we use beneath self written scripts the following packages:
* glib2-devel: glib-gettextize      
* gettext, probably broken in:
** -runtime: msgfmt, ...
** -tools: (autopoint), gettextize, msg*, xgettext, ...
** -runtime-tools-doc: manuals etc.
* intltool: Intltool*

====IntlTool====
From [http://freedesktop.org/wiki/Software/intltool/ freedesktop Software/intltools] intro, last edited Sat 18 May 2013 05:42:11 PM PDT:
:intltool is a set of tools to centralize translation of many different file formats using GNU gettext-compatible PO files.
:The intltool collection can be used to do these things:
:* Extract translatable strings from various source files (.xml.in,glade, .desktop.in, .server.in, .oaf.in).
:* Collect the extracted strings together with messages from traditional source files (.c, .h) in po/$(PACKAGE).pot.
:* Merge back the translations from .po files into .xml, .desktop and oaf files. This merge step will happen at build resp. installation time.

And in the more recent [https://launchpad.net/intltool Launchpad Internationalization Tool Collection site] it seems to concentrate on xml. 

'''Conclusio''': In case we remove it from gnucash.git, we should not remove it from gnucash-docs as IIRC at least one translation is using it - I didn't check htdocs.

Googles first hit for "'''Intltool''' manaual" is [https://wiki.gnome.org/TranslationProject/DevGuidelines/Localize%20using%20gettext%20and%20intltool Localize using gettext and intltool], which starts with
: This page consists of some parts from Christian Rose's L10N Guidelines for Developers document that could not be moved anywhere else. It does not provide enough information on localization your application, and may be outdated. Please look for additional resources for developers at TranslationProject wiki pages.
: Ideally, this will be integrated together with Malcolm Treddinick's Internationalising GNOME application document and GnomeI18nDeveloperTips wiki page.

=== Our Build Process ===
The build process goes through the following scipts:
 
====== autogen.sh ======
;glib-gettextize: helps to prepare a source package for being internationalized through gettext. It is a ''variant of the gettextize'' that ships with gettext. 
:glib-gettextize differs from gettextize in that it doesn't create an intl/ subdirectory and doesn't modify po/ChangeLog (note that newer versions of gettextize behave like this when called with the --no-changelog option).

»Note that on GNU systems, you ''don't need to link with libintl'' because the '''gettext library functions are already contained in GNU libc'''.« (glibc) [http://www.gnu.org/software/gettext/manual/gettext.html#Overview]

;intltoolize: copy intltool related files to software package

====== configure.ac ======
* Sets
 ALL_LINGUAS= ...
In recent versions it can be substituted by LINGUAS files in the po directories. We should consider this to distinguish TP vs. GC maintained translations.
 GETTEXT_PACKAGE=gnucash
This is intltool style. Gettext uses PACKAGE=...
 AC_SUBST(GETTEXT_PACKAGE)
 AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, "$GETTEXT_PACKAGE",
    [GetText version number])

AM_GNU_GETTEXT_VERSION(x.yy.zz) can be used to require a version. We should use it to avoid ...
* TP expects > 0.11.
* intltool-update checks for GNU gettext >= 0.12
* gnulib expects >= 0.17
* RHEL7 offers 0.18.2 (RHEL6 0.17)
* Debian Stable offers 0.18.1 and in backport 0.19.3
* Glade2 msgctxt and Glade3 were implemented in 0.18.3 - July 2013
* GSettings and Desktop entries are implemented in 0.19 - June 2014
* and got bugfixes until Version 0.19.3 - October 2014
* Scheme format strings got a fix in 0.19.4 - December 2014

This setting then can be used by autoPoInt. Watch the caveaets from https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html:
: On the other hand, if your package is not as concerned with compliance to the latest standards, but instead favors development on stable environments, the steps are:
:# Determine the oldest version of gettext that you intend to support during development (at this time, gnulib recommends going no older than version 0.17). Run autopoint (not gettextize) to copy infrastructure into place (newer versions of gettext will install the older infrastructure that you requested).
:# Invoke gnulib-tool, and import the gettext-h module. # Fixme: Meaning?

:Regardless of which approach you used to get the infrastructure in place, the following steps must then be used to preserve that infrastructure (gnulib’s bootstrap script follows these rules):
:# When a script of yours run autopoint, invoke gnulib-tool afterwards.
:# When you invoke autoreconf after gnulib-tool, make sure to not invoke autopoint a second time, by setting the AUTOPOINT environment variable, like this:
::<pre>$ env AUTOPOINT=true autoreconf --install</pre>

 AM_GLIB_GNU_GETTEXT          # FIXME: Meaning?
*runs checks with settings
** AC_PROG_INTLTOOL
** AC_CHECK_HEADERS(ltdl.h, ...
 dnl Make sure we have a proper gettext installed
 AC_MSG_CHECKING(for a valid gettext/gmsgfmt installation)
 if test "$gt_cv_have_gettext" != "yes" || test "x$GMSGFMT" = "x"; then
   AC_MSG_RESULT(no)
   AC_MSG_ERROR([Cannot find Glib Gettext.  Maybe you need to install the gettext package?])
 else
   AC_MSG_RESULT(yes - $GMSGFMT)
 fi

====== makefile.am ======
has the following section:
 .PHONY: pot
 pot: Makefile po/POTFILES.in
 	rm -f po/$(PACKAGE).pot
 	${MAKE} -C po $(PACKAGE).pot
 
 
 $(srcdir)/po/POTFILES.in: make-gnucash-potfiles .potfiles
 	if test -w $(srcdir)/po/POTFILES.in ; then ./'''make-gnucash-potfiles''' > $(srcdir)/po/POTFILES.in ; fi
 
 # Creation rules so that po/gnucash.pot can always be created for
 # make dist.
 po/gnucash.pot: po/POTFILES.in
 	${MAKE} -C po gnucash.pot
 
 .potfiles:

====== make-gnucash-potfile.in ======
This is a self written perl script from the time as gettext had several issues. It creates '''po/potfiles.in''', the "list of files which contain translatable strings".


====== po/makefile.in.in ======
This is always copied from your installed intltool package. It contains <pre>
MSGMERGE = INTLTOOL_EXTRACT="$(INTLTOOL_EXTRACT)" XGETTEXT="$(XGETTEXT)" srcdir=$(srcdir) $(INTLTOOL_UPDATE) --gettext-package $(GETTEXT_PACKAGE) --dist
GENPOT   = INTLTOOL_EXTRACT="$(INTLTOOL_EXTRACT)" XGETTEXT="$(XGETTEXT)" srcdir=$(srcdir) $(INTLTOOL_UPDATE) --gettext-package $(GETTEXT_PACKAGE) --pot</pre>
So it calls in both cases intltool-update with different parameters.

There are several commands in the packages with overlapping funtionality:

;intltool-prepare: Extracts all localized strings in .desktop style files (including ".desktop", ".soundlist", ".keys" and ".directory") ''into corresponding '''po''' files''. See <code>man:/intltool-prepare(8)</code>

;intltool-extract: extracts strings in the specified XML/INI type SOURCE_FILE and writes them ''into a '''C header''' file''. Currently supported types are: 
:"gettext/glade" (.glade, .glade2) 
:"gettext/gsettings" (.gschema.xml) 
:"gettext/ini" (Generic INI file) 
:"gettext/keys" (.keys) 
:"gettext/rfc822deb" (RFC 822 format file) Debian configuration files
:"gettext/quoted" (all strings within "") 
:"gettext/schemas" (.schemas) 
:"gettext/scheme" (.scm) 
:"gettext/xml" (Generic XML file)

;xgettext: Extract translatable strings from given input files. See --language for supported list:
:;--language=NAME: recognise the specified language ('''C''', '''C++''', ObjectiveC, PO, Shell, ''Python'', Lisp, EmacsLisp, librep, '''Scheme''', Smalltalk, Java, JavaProperties, C#, awk, YCP, Tcl, ''Perl'', PHP, GCC-source, NXStringTable, RST, '''Glade''', Lua, JavaScript, Vala, '''Desktop''') 
:Options, which we should check:
:;--copyright-holder=STRING: set copyright holder in output
:;--foreign-user: omit FSF copyright in output for foreign user
:;--msgid-bugs-address=EMAIL@ADDRESS: set report address for msgid bugs

;intltool-update: ''updates PO template file'' and merge translations with it. You must change working directory to the subdirectory containing translations (usually "po/") before running intltool-update. Special options:
:;--maintain: Search for left out files, which should have been listed in POTFILES.in or POTFILES.skip. A list of all these files are written into another file called "missing".
:;--headers: Executes intltool-extract(8) to extract strings inside XML/INI style files listed in POTFILES.in, and writes the extracted strings into header files, so that the strings can be recognised by xgettext(1).
:;--report: Display a status report for all translations in the software.
:;Warning: Usually you will not want to commit the changed .po files!

;intltool-merge: merge translated strings into various types of file

----------------------------------------------------------------------

[[Category:Translation]]