The string(s) following the msgid tag is the Key, i.e the Original String. The string(s) following the msgstr tag is the Value, i.e the Translated String that will be presented in place of the Original String.

+

The string(s) following the '''msgid''' tag is the Key, i.e the ''Original String''.

+

The string(s) following the '''msgstr''' tag is the Value, i.e the ''Translated String''

+

that will be presented in place of the Original String.

Using gettext you can create an initial PO-file containing all the strings of your application that should be possible to translate. By translating the strings into some other language and loading the new PO-file into the gettext DB you can adapt your application for different languages.

Using gettext you can create an initial PO-file containing all the strings of your application that should be possible to translate. By translating the strings into some other language and loading the new PO-file into the gettext DB you can adapt your application for different languages.

−

Note that the very first entry of the PO file is a bit special since it contains meta-information. Especially important is the charset information. It is important that you set this right when doing a translation. If you store the strings in utf-8 format then put that info in the PO-file.

+

Note that the very first entry of the PO file is a bit special since it contains meta-information. Especially important is the charset information. It is important that you set this right when doing a translation. If you store the strings in ''utf-8'' format then put that info in the PO-file.

'''Example of the charset info in the PO-file:'''

'''Example of the charset info in the PO-file:'''

Line 70:

Line 75:

In your Erlang or Yaws file, whenever you have a string that should be possible to present in a different language, you wrap it with one of the gettext macros ?TXT/1 or ?TXT2/1.

In your Erlang or Yaws file, whenever you have a string that should be possible to present in a different language, you wrap it with one of the gettext macros ?TXT/1 or ?TXT2/1.

−

'''Example of how to use the TXT macros:'''

+

'''Example of how to use the TXT2 macro:'''

-include(".../gettext/include/gettext.hrl").

-include(".../gettext/include/gettext.hrl").

Line 77:

Line 82:

?TXT2("Hello World", LangCode).

?TXT2("Hello World", LangCode).

−

The ?TXT macro will be substituted with a call to: ''gettext:key2str("Hello World", LangCode)''. This function will try to lookup the string "Hello World" in the LangCode-DB (database). If no such DB can be found the string will just be returned as is. This way no string will ever disappear since it (at least) always will fallback to the original string.

+

The '''?TXT2''' macro will be substituted with a call to: ''gettext:key2str("Hello World", LangCode)''. This function will try to lookup the string "Hello World" in the LangCode-DB (database). If no such DB can be found the string will just be returned as is. This way no string will ever disappear since it (at least) always will fallback to the original string.

−

To make it extra convenient, you can use the ?TXT macro which just takes one argument and expands to: ''gettext:key2str("Hello World", get(gettext_language))''. As you can see it assume that you already have put the language code into the process dictionary using the key: gettext_language. This is useful for example in a Yaws application where you perhaps get the prefered language code from the headers of the HTTP request. Just put the language code into the process dictonary and you are done!

+

To make it extra convenient, you can use the '''?TXT''' macro which just takes one argument and expands to: ''gettext:key2str("Hello World", get(gettext_language))''. As you can see it assume that you already have put the language code into the process dictionary using the key: gettext_language. This is useful for example in a Yaws application where you perhaps get the prefered language code from the headers of the HTTP request. Just put the language code into the process dictionary and you are done!

+

+

'''Example of how to use some other TXT macros:'''

+

+

-include(".../gettext/include/gettext.hrl").

+

+

hello(LangCode) -&gt;

+

put(gettext_language, LangCode),

+

?TXT("Hello World"),

+

?FTXT("Hello ~s", ["World"]).

+

+

Note the last line above! The '''?FTXT''' macro makes it possible to do argument

+

substitution just as with io:format/2 and friends.

===The gettext database===

===The gettext database===

There are two ways you can control where the gettext database is located. The first way is to set the environment variable: GETTEXT_DIR to point to the directory where you want gettext to store its data. The second way is to provide a callback function named: gettext_dir/0. You specify the module, either by setting the environment variable GETTEXT_CBMOD, or by giving it as an argument in your supervisor code that setup the gettext_server (see example in gettext_sup.erl).

There are two ways you can control where the gettext database is located. The first way is to set the environment variable: GETTEXT_DIR to point to the directory where you want gettext to store its data. The second way is to provide a callback function named: gettext_dir/0. You specify the module, either by setting the environment variable GETTEXT_CBMOD, or by giving it as an argument in your supervisor code that setup the gettext_server (see example in gettext_sup.erl).

+

+

If nothing of the above are used; as a last resort, gettext will try to use its own ''priv'' directory as the

+

the location for its database and the PO-files.

'''Example, the callback module.'''

'''Example, the callback module.'''

Line 98:

Line 118:

The dets file contains the actual lookup database. The default directory will only contain one subdirectory with the name of your default language (e.g "en" as in english). The custom directory will contain one subdirectory for each language you have, each subdirectory containing a translated gettext.po file.

The dets file contains the actual lookup database. The default directory will only contain one subdirectory with the name of your default language (e.g "en" as in english). The custom directory will contain one subdirectory for each language you have, each subdirectory containing a translated gettext.po file.

−

If you want add a translated PO-file to your DB you call the function: gettext_server:store_pofile(LanguageCode, BinPOfile) See also the example section below.

+

If you want add a translated PO-file to your DB you call the function:

+

'''gettext_server:store_pofile(LanguageCode, BinPOfile)'''

+

See also the example section below.

===How to create the 'initial' PO-file.===

===How to create the 'initial' PO-file.===

Line 232:

Line 254:

===Final remarks.===

===Final remarks.===

−

<p>You can easily write some code on top of this to make it

−

possible to export the initial PO-file and to import translated

−

PO-files. Also, take a look at the ''iso639.erl'' file which can

−

be helpful if you want to present some standardized language

−

codes and their full language names.

−

</p>

−

<p>If you run a Web application, it is important that you tell

+

You can easily write some code on top of this to make it

−

the Web browser what character set you are using. To support

+

possible to export the initial PO-file and to import translated

−

this, you can use the function: ''gettext_server:lang2cset(LanguageCode)

+

PO-files. Just make sure that you store the imported PO-file

−

This way you can make sure that the browser can display your

+

in according to the gettext directory structure.

−

pages correctly. It is even possible to convert from the

+

Also, take a look at the ''iso639.erl'' file which can

−

character set you have to what the Web browser wants if

+

be helpful if you want to present some standardized language

−

you make use of the 'iconv' library that exist in jungerl. But that is another story...</p>

+

codes and their full language names.

+

+

Below follows a couple of useful gettext functions. For example,

+

if you have a running system and have an updated language translation

+

on disk, then use the '''gettext:reload_custom_lang/1''' function to

+

load the new translations into the gettext DB.

+

+

'''Some other nice gettext functions:'''

+

+

%% reload a custom language into the gettext DB

+

1&gt; gettext:reload_custom_lang("nb").

+

ok

+

+

%% show what languages we have loaded in the gettext DB

+

2&gt; gettext:all_lcs().

+

["nb","sv"]

+

+

%% remove a custom language from the gettext DB

+

3&gt; gettext:unload_custom_lang("nb").

+

ok

+

4&gt; gettext:all_lcs().

+

["sv"]

+

+

%% re-build the gettext DB

+

5&gt; gettext:recreate_db().

+

ok

+

+

+

If you run a Web application, it is important that you tell

+

the Web browser what character set you are using. To support

+

this, you can use the function: ''gettext_server:lang2cset(LanguageCode)

+

This way you can make sure that the browser can display your

+

pages correctly. It is even possible to convert from the

+

character set you have to what the Web browser wants if

+

you make use of the 'iconv' library that exist in jungerl. But that is another story...

Author

Tobbe

Gettext

Introduction

The gettext application makes it possible to internationalize your application. For example, if you have a Web application where you want to present information in different languages, you can accomplish that with the gettext application.

The name gettext comes from the GNU package with the same name. Note however that the only thing they have in common is the format of the PO-files, i.e the files containing the text that can be translated. A PO file contains the Original String and the Translated String.

Example of a PO entry generated by gettext:

#: esmb_gettext.erl:13
msgid ""
"Hello World"
msgstr ""
"Hej Värld"

The string(s) following the msgid tag is the Key, i.e the Original String.
The string(s) following the msgstr tag is the Value, i.e the Translated String
that will be presented in place of the Original String.

Using gettext you can create an initial PO-file containing all the strings of your application that should be possible to translate. By translating the strings into some other language and loading the new PO-file into the gettext DB you can adapt your application for different languages.

Note that the very first entry of the PO file is a bit special since it contains meta-information. Especially important is the charset information. It is important that you set this right when doing a translation. If you store the strings in utf-8 format then put that info in the PO-file.

The ?TXT2 macro will be substituted with a call to: gettext:key2str("Hello World", LangCode). This function will try to lookup the string "Hello World" in the LangCode-DB (database). If no such DB can be found the string will just be returned as is. This way no string will ever disappear since it (at least) always will fallback to the original string.

To make it extra convenient, you can use the ?TXT macro which just takes one argument and expands to: gettext:key2str("Hello World", get(gettext_language)). As you can see it assume that you already have put the language code into the process dictionary using the key: gettext_language. This is useful for example in a Yaws application where you perhaps get the prefered language code from the headers of the HTTP request. Just put the language code into the process dictionary and you are done!

Note the last line above! The ?FTXT macro makes it possible to do argument
substitution just as with io:format/2 and friends.

The gettext database

There are two ways you can control where the gettext database is located. The first way is to set the environment variable: GETTEXT_DIR to point to the directory where you want gettext to store its data. The second way is to provide a callback function named: gettext_dir/0. You specify the module, either by setting the environment variable GETTEXT_CBMOD, or by giving it as an argument in your supervisor code that setup the gettext_server (see example in gettext_sup.erl).

If nothing of the above are used; as a last resort, gettext will try to use its own priv directory as the
the location for its database and the PO-files.

The dets file contains the actual lookup database. The default directory will only contain one subdirectory with the name of your default language (e.g "en" as in english). The custom directory will contain one subdirectory for each language you have, each subdirectory containing a translated gettext.po file.

If you want add a translated PO-file to your DB you call the function:
gettext_server:store_pofile(LanguageCode, BinPOfile)
See also the example section below.

How to create the 'initial' PO-file.

This step requires you to setup some Makefile support in your build environment.

The jungerl version of gettext has a simple example prepared for you to look at. The top gettext Makefile contains a target jungerl_example which will run make using the Makefile.gettext makefile.

Take a look at the Makefile.gettext file. At the top you specify the directories that should be processed, i.e where there are code containing ?TXT macros. As you can see from the example; we have specified that it is the esmb application that should be processed. We also specify where the 'gettext' data dir is located.

Then, for each directory to be processed, we run make with a special target named gettext. If you look into the esmb application you can see that its top Makefile has got such a target. All this target needs to do is to remove any dependency files (e.g beam files) and then run make to compile them again.

All source files that are using the ?TXT macro are also including the gettext/include/gettext.hrl file which contains a parse-transform. This parse-transform will store all strings that was wrapped with the ?TXT macro into a temporary database.

Going back to the Makefile.gettext file again you can see that when all processing is finished, we call a last generation step. Where we will extract all data from the temporary DB and generate the 'initial' PO-file.

Example session.

Here follows an example session showing how to use gettext. We start by creating our database directory and generate the initial PO-file.

Final remarks.

You can easily write some code on top of this to make it
possible to export the initial PO-file and to import translated
PO-files. Just make sure that you store the imported PO-file
in according to the gettext directory structure.
Also, take a look at the iso639.erl file which can
be helpful if you want to present some standardized language
codes and their full language names.

Below follows a couple of useful gettext functions. For example,
if you have a running system and have an updated language translation
on disk, then use the gettext:reload_custom_lang/1 function to
load the new translations into the gettext DB.

If you run a Web application, it is important that you tell
the Web browser what character set you are using. To support
this, you can use the function: gettext_server:lang2cset(LanguageCode)
This way you can make sure that the browser can display your
pages correctly. It is even possible to convert from the
character set you have to what the Web browser wants if
you make use of the 'iconv' library that exist in jungerl. But that is another story...