Where and how should I write translations

[Martin Tiršel]

Hello,

I can not find in Django documentation a word about translating variables
or strings with variables. I have:

...
<legend>{% trans question_category %}</legend>
...

django-admin.py makemessages creates .po but without a mention about this
template line ({% trans "some text" %} is ok). It is clear, that I have
somehow to specify translation strings in .po file, but when I do it
manually, next django-admin.py makemessages overwrite the .po file.

So, my question is, where and how should I write translation for strings
in variables (or variable in a string)?

Next, I have some strings in initial_data.json fixture, is there a way how
to automatically extract it into .po file while running django-admin.py
makemessages? Or it could extract it from database, it doesn't matter.
Yes, I know, that I should change DB structure and not translate strings
from DB this way, but I have my reasons why I am doing it so.

Thanks,
Martin

[Martin Tiršel]

I tried to create second .po file with manual translations, but had no
luck either :( `compilemessages` creates the second .mo file, but doesn't
use it in the app. Only django.mo is used, but all my translations in
django.po file are commented out after I run `makemessages`.

In the documentation:

"(The caveat with using variables or computed values, as in the previous
two examples, is that Django's translation-string-detecting utility,
django-admin.py makemessages, won't be able to find these strings. More on
makemessages later.)"

But there is no "later" :(

Thanks,
Martin

On Thu, 02 Sep 2010 13:33:36 +0200, Martin Tiršel <dja...@blackpage.eu>
wrote:

[Tom Evans]

On Thu, Sep 2, 2010 at 2:15 PM, Martin Tiršel <dja...@blackpage.eu> wrote:
> I tried to create second .po file with manual translations, but had no luck
> either :( `compilemessages` creates the second .mo file, but doesn't use it
> in the app. Only django.mo is used, but all my translations in django.po
> file are commented out after I run `makemessages`.
>
> In the documentation:
>
> "(The caveat with using variables or computed values, as in the previous two
> examples, is that Django's translation-string-detecting utility,
> django-admin.py makemessages, won't be able to find these strings. More on
> makemessages later.)"
>
> But there is no "later" :(
>
> Thanks,
> Martin
>

I had to do some clever things to import languages names from the
CLDR. I ended up writing a small management command (sorry, can't
share the entire thing) which first of all runs makemessages for each
language. This generates/updates the django.po files for each
language.

I then step through each of the languages, load the CLDR xml file, and
manually update the generated po file, inserting/updating entries as
necessary. Having added all the extra translations, I then run
compilemessages, so they are always available.

To update the po file, I use polib - which you can get standalone, but
is also a part of the amazing django-rosetta.

The code to add/update entries using polib is pretty straightforward.
First load the po file, look for your key, if it isn't there add it.
In code:

for (lang, name) in settings.LANGUAGES:
lang_po_path = os.path.join(settings.PROJECT_ROOT, '<projname>',
'locale', lang, 'LC_MESSAGES', 'django.po')
po = polib.pofile(lang_po_path)
cldr = self.load_cldr_data(lang, ccodes)
for code in ccodes:
idx = u'Country code %s' % code
try:
trans = cldr[code]
except KeyError:
self.debug("No translation for country code %s" % code)
continue
entry = po.find(idx)
if entry:
entry.msgstr = trans
entry.obsolete = 0
else:
entry = polib.POEntry(msgid=idx, msgstr=trans)
entry.occurrences = [ ('Common Locale Data Repository', 1), ]
entry.comment = 'Country name, imported from CLDR (Do not
manually translate, translation is automatically updated!)'
entry.tcomment = entry.comment
entry.obsolete = 0
po.append(entry)
po.save()

Obviously, with your problem, you aren't adding the actual
translations, just the msg id, so don't set msgstr. In this example,
I'm adding translations for 'Country code AD' -> 'Country code ZW'
(which will now translate into 'Andorra' -> 'Zimbabwe' :)

Cheers

Tom

[Martin Tiršel]

Never heard about CLDR before, so your answer doesn't give much sense to
me :( Django doesn't have complete implementation of internationalization?
makemessages is then useless if I can not add custom strings without
overwriting them by Django. Or is there really something I don't know
about?

Thanks,
Martin

On Thu, 02 Sep 2010 17:03:01 +0200, Tom Evans <teva...@googlemail.com>
wrote:

[Martin Tiršel]

I solved it by creating a new python file with:

# -*- coding: utf-8 -*-
from django.utils.translation import ugettext as _

translation_strings = [
_(u'string'),
_(u'another string'),
...
]

So easy :)

Martin

On Thu, 02 Sep 2010 13:33:36 +0200, Martin Tiršel <dja...@blackpage.eu>
wrote:

> Hello,

[Tom Evans]

Never heard about google either? CLDR can hardly be a common acronym.

Django has a complete implementation of internationalization. It knows
how to extract translations from python files, from HTML files, from
JS files and compile them into catalogues.

You want to have django magically extract additional translations from
somewhere other than this. To do that, you have to do more than django
does.

I explained how you could do that for translations that came from
another source, in this case the XML files from the Common Locale Data
Repository, which contains country names, language names, script
names, currency names etc for every locale on the planet.

I also explained how you could hook your extra translations into the
makemessages/compilemessages process.

Which bits were unclear?

Cheers

Tom

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>