Translations for country names. #1
Comments
Feel free, if not compelled, to fork the project and create a |
|
I can do it, but I'm not focused on app right now. just see it in django When I touch your app again I'll think about whole thing. Translations on DB is most obvious but not sounds good when many people A message file in this case sounds much better. I guess that best shot is a translation file and cache for translations. One simple translation method can push translations to a memcached ... Cheers Felipe 'chronos' Prenholato. 2012/2/19 rfkrocktk <
|
ghost
assigned 
|
I've created a management command that receives a locale and creates a messages file for it with all the objects from the database, and added a translated_name property to both models which returns |
|
Cool, thanks so much. You want to take everything out of the database, though? Part of the whole theory of the project is to keep everything in the database if possible so that other objects can actually own country and territory objects, ie: This gives a lot greater flexibility than simply embedding things in messages files. Plus, if you implement memcached and a query cache, you could presumably just cache the entire Why implement things in messages files when you get more functionality and (with the right configuration) equal or better performance when in the database? @Lacrymology I'm totally for what you're suggesting, but I dunno, I just like having things in the database. Call me crazy, but it just seems so much cooler that way. Perhaps a bigger scope is in order. It might be wise to just create a |
|
I don't think filling the database with tons of strings sounds like a good idea. I don't like having two different objects that represent the same thing. Of course, both approaches work, but I don't see what's the gain in having the translations in the database. |
|
Oh, and I don't want to take anything out of the database. But I wouldn't put translations in, that's it. The thing with translations is that sharing fixtures around is a real pain |
|
Now that you mention it, it might be wise to just keep the translations local. They can be tied to each country by its The only thing I think we're really losing is interoperability with other applications; if the translations are stored in the database, then other applications can access them as well. (eg: if you have Django for your web front and Java as an asynchronous task runner which pulls things from the database, it would have to pull in the message files to get translations for country names.) |
|
My 2 cents o talk: Keep in database is really good for interoperability, but maintain fixtures At other side, .mo files is just files and can be easily merged by team Cheers, Felipe 'chronos' Prenholato. 2012/3/12 rfkrocktk <
|
|
Since we're doing everything in fixtures anyway, your argument isn't valid: simply examine the An alternative approach would be to essentially merge the two ideas; provide translation files, but as a fixture, import them and send them to the database when |
|
@rfkrocktk have you actually tried working on fixtures with two or three people? I do it to develop django-cms based sites, and it's REALLY a pain. True, it is rather bigger than this, but still.. I still don't see how would some javascript talk straight to the database. You'll be calling on a view, which can do whatever it wants with the country/territory names before returning them. For example (I just realized I might have used the _lazy flavour of ugettext which wouldn't work in this case) |
|
@Lacrymology, it wouldn't be JavaScript, it'd be Python. Essentially, I'd listen for the |
|
Sirs, polib can read .po files so we can import it to database very easily, so we easily maintain .po files with country translations, and with one management command, can import it to database. See: In [1]: import polib
In [2]: po = polib.pofile('/home/felipe/projects/p3/src/django/django/conf/locale/pt_BR/LC_MESSAGES/django.po')
In [3]: po.translated_entries()[0].__dict__
Out[3]:
{'comment': '',
'encoding': 'utf-8',
'flags': [],
'msgctxt': None,
'msgid': u'Arabic',
'msgid_plural': '',
'msgstr': u'\xc1rabe',
'msgstr_plural': {},
'obsolete': 0,
'occurrences': [(u'conf/global_settings.py', u'44')],
'previous_msgctxt': None,
'previous_msgid': None,
'previous_msgid_plural': None,
'tcomment': ''} |
|
Nice. I haven't worked with |
|
@rfkrocktk oh, you said Java, not javascript. My bad |
|
@Lacrymology yeah, just talking about some other generic service (could by anything, PHP, Java, whatever) using the same database as Django. It happens. |
|
Good, so we can create a .PO file with all country names in locale/en/LC_MESSAGES/django.po and use this one as template to other languages. We (and I'm on that task) can work on the reader using polib and import it to the model CountryTranslations I mentioned on firtst post, but following scope sugested by @rfkrocktk . In templates, and in any place that don't need a hit in DB for get translation, will be used ugettext (or the lazy version). For interoperability with other applications database with translations can be read. More some idea on that? Considerations? |
|
Just to log, I get from pycountry project a full list of locales. Guys can found at http://devwithpassion.com/locale_codes.txt |
|
Finishing works for today, I have hacked around pycountry a bit and defined models for translations. In my hacking I see that pycountry (http://pypi.python.org/pypi/pycountry) have most translations that we want, so we only need to work with pycountry to load translations into database, providing the 'interoperability'. There is one package, the djangool (https://github.com/cilcoberlin/djangoool) that provide models to use in database for data existent in pycountry. We can do same. I guess that the best about translations is use the ones provided by pycountry, but I don't know (and will look only tomorrow) if django have support to external .mo files in templates, etc. Here is how I imported translations for pt_BR. The code is at https://github.com/chronossc/django-locality/tree/chronossc and this branch have @Lacrymology changes merged. |
and others
Hello :], this is a idea and not a real issue.
What about allow country name translations?
We can have a table like:
We have a list of possible language codes in locale module (or we can search on other places).
Also, we can put it in gettext files in some way, so we can keep it versioned and without need of fixtures.
What u think about?
The text was updated successfully, but these errors were encountered: