I'm using gettext to handle translations on a C++ project of mine. I generate the .pot file using xgettext and then I create .po files for spanish and english using msginit (en.po and es.po) .
The problem is that, although the locale on my system is set to spanish, the .po file that gets automatically filled is en.po, where it should be es.po, because all strings are by default written in spanish in my project. All in all, the content from en.po should be the one in es.po and viceversa.
Is there a way of letting xgettext and/or msginit that spanish is the default language?
Using other languages than English as the base language of your project has been considered a recipe for trouble for a long time. This is no longer true today.
With msginit 0.19.8.1, when you run msginit -l en -i project.pot, the file en.po gets created but all translations are initialized with their original value. Obviously msginit assumes that English is the base language of the project. But that can be easily fixed: Just open the en.po in your editor and throw away all entries but the first one (the PO header).
When invoking xgettext you should always give it the option --from-code=utf-8. Other than that there are no problems to use another base language than English.
Related
I am trying to translate django contrib strings which for my language are untranslated in the original .po file. When I add them to my own .po file and translate them, the system works fine. The problem comes every time I use the makemessages command, since the generator interprets that those text strings have been deleted and comments them in the .po file. Can I hand generate a file that contains the translations and is not affected by the makemessages command? On the other hand, is it possible to tell him not to comment on the deleted lines?
The most effective would be probably to contribute directly to the Django project to provide those translations so they are included in the next version!
See "Localizing Django" for details.
We've been maintaining a Django website with a few Mac and Linux users (through GitHub), but now a Windows-only person joined the team.
We've come to one annoying little difference concerning the creation of .po localisation files.
So far, we've always had paths with forward slashes: #: core/templates/home.html:8, but the Windows user generates paths with backslashes: #: .\core\templates\home.html:8.
This makes it much more difficult to spot changes, since 750+ lines change everytime, rather than only the new or changed text & translations.
I tried myself on a Windows computer and have the same result.
What can we do to unify this?
Thanks!
Edit: to clarify, we're a small team without dedicated (external) translators. Whoever changes or adds stuff, generally should also add and update the localisation files.
You can create your own makemessages command (django.core.management.commands.makemessages), based on the original. All you need to do is subclass BuildFile, overriding postprocess_messages to replace the slashes.
Then you subclass Command to use your own BuildFile subclass (it's just a class attribute build_file_class).
While developing and translating an application, it might be nice if gettext will use the catalogs found in the local po/ dir so it wouldn't be necessary to call make install each time.
Is there a way to do it?
One of the problems is the naming convention: gettext looks for the catalog files in an hierarchy that looks like /usr/share/locale/LL/LC_MESSAGES/package.mo (where LL is two-letter language code), while usually in the development tree the binary catalogs reside in po/LL.gmo.
it might be nice if gettext will use the catalogs found in the local po/ dir so it wouldn't be necessary to call make install each time....Is there a way to do it?
If I am understanding your idea correctly, it sounds like gettext is able to do just that (i.e. change the translation path variable) if you follow the prescribed methods to set it up...
Translations should be stored in a path having a fixed structure.
First of all, we’ll have a root folder named to your taste (for
example “languages”). Inside it, we have to create a folder for every
targeted language whose name must comply to the ISO 3166 standard. So,
valid names for an Italian translation can be “it_IT” (Italian of
Italy), “it_CH” (Italian of Switzerland), “en_US” (English of USA),
and so on. Within the folder having the language code, we must have a
folder named “LC_MESSAGES” where, finally, we’ll store the translation
files.
From Here (there is a script example included in this link showing one method to perform this task)
Change "languages" in description above to "po", and that may do what you want?
I am creating an OpenGL game and I would like to make it open to more languages than just English for obvious reasons. From looking around and fiddling around with the games installed on my computer I can see that locales play a big part in this and that .lang files, such as en-US.lang that is shipped with minecraft, are basically text documents with a language code, "item.iron.ingot" for example, an equal sign, and then what it means for that given language, English as per en-US, so in this case would be, "Iron Ingot". Well I created a file that I named en-US.lang and this is its contents:
item.iron.ingot=Iron Ingot
In my C++ main method I put:
setlocale(LC_ALL, "en-US");
After including the locale header file. So I suppose the part that I am confused by is how to use the locales to read from the .lang file? Please help SO and some example code would be appreciated.
C++ Does not come with a built-in support for resource files / internationalization. However there is a huge variety of solutions.
To support multi-language messages, you should have some basic understanding of how such strings are encoded in files and read to memory. Here is a basic introduction if you are not familiar:
"http://www.joelonsoftware.com/articles/Unicode.html"
To keep and load the correct text at runtime you need to use a third party library: GNU gettext http://www.gnu.org/software/gettext/ is one such example. However there are other solutions out there.
I maintain a pluggable Django app that contains translations. All strings in Python and HTML code are written in English. When translating the strings to German, I'm always fighting with the problem that German differentiates between formal and informal speech (see T–V distinction). Because the app is used on different sites, ranging from a social network to a banking website, I can't just support either the formal or informal version. And since the translations can differ quite a bit, there's no way I can parameterize it. E.g. the sentence "Do you want to log out?" would have these two translations:
Wollen Sie sich abmelden? (formal)
Willst du dich abmelden? (informal)
Is there anything in Gettext that could help me with this?
You can use contextual markers to give your translations additional context.
logout = pgettext('casual', 'Do you want to log out?')
...
logout = pgettext('formal', 'Do you want to log out?')
The best approach, used in other similar situations by gettext as well as UNIX is to use locale variants. For example, sr_RS is (or was, because Serbian is considered a metalanguage these days...) code used for Serbian written in Cyrillic. But it’s sometimes written in Latin script too, so sr_RS#latin is used as the language name and of course, the MO filename or directory as well.
Here, have a look at some translations I have present on my system:
$ find /usr/local/share/locale | grep /sr
/usr/local/share/locale/sr
/usr/local/share/locale/sr/LC_MESSAGES
/usr/local/share/locale/sr/LC_MESSAGES/bash.mo
/usr/local/share/locale/sr/LC_MESSAGES/bfd.mo
/usr/local/share/locale/sr/LC_MESSAGES/binutils.mo
/usr/local/share/locale/sr/LC_MESSAGES/gettext-runtime.mo
/usr/local/share/locale/sr/LC_MESSAGES/gettext-tools.mo
/usr/local/share/locale/sr/LC_MESSAGES/glib20.mo
/usr/local/share/locale/sr/LC_MESSAGES/wget.mo
/usr/local/share/locale/sr#ije
/usr/local/share/locale/sr#ije/LC_MESSAGES
/usr/local/share/locale/sr#ije/LC_MESSAGES/glib20.mo
/usr/local/share/locale/sr#latin
/usr/local/share/locale/sr#latin/LC_MESSAGES
/usr/local/share/locale/sr#latin/LC_MESSAGES/glib20.mo
/usr/local/share/locale/sr_RS
/usr/local/share/locale/sr_RS/LC_MESSAGES
/usr/local/share/locale/sr_RS/LC_MESSAGES/mkvtoolnix.mo
/usr/local/share/locale/sr_RS#latin
/usr/local/share/locale/sr_RS#latin/LC_MESSAGES
/usr/local/share/locale/sr_RS#latin/LC_MESSAGES/mkvtoolnix.mo
$
So the best way to handle German variants is the same: use de (or de_DE) for the base informal variant and have a separate translation file de_DE#formal with the formal variant of the translation.
This is basically what WordPress does too. Of course, being WordPress, they have their own special flavour and don’t use the variant syntax, but instead add a third component to the filename: de_DE.mo is the informal (and also fallback, because it lacks any further specification) variant and de_DE_formal.mo contains the formal variant.