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
On Sun, Sep 5, 2010 at 1:08 AM, Martin Tiršel <dja...@blackpage.eu> wrote:
> 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 <tevans...@googlemail.com>
> wrote:
>
>> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
