On Mon, May 24, 2010 at 01:47:14AM -0700, Pascal wrote: > From what I've read so far, using translation "tags" (or quick > phrases) in the code, and translating them to every target language > (including english) sounds a better approach than using, for example, > final english wordings as translation tags. The setup is longer via > the first way, but at least if you change english wordings later, you > don't break all other translations at the same time.
This is an interesting point. I'm using both "tags" and final wordings, albeit my goal is differently translating some strings that are the same in English. Not breaking other translations sounds tempting, especially if you have many; however, the result will depend on how you change the text: If you change its meaning (which does happen), then you do want the translations to break, and have to ensure that you change the "tag", too; TBH, I'm too lazy to think about that :) . > * code safety : it seems default python string formatting technics (% > operator, .format() method) are normally used when one needs to > substitute placeholders in translated strings. But the thing is : I > DONT want my view to raise an exception simply because one of the > translations has forgotten a damn "%(myvar)s" placeholder. The only > quick fix I can think of, is to always use substitution through > defaultdicts instances (and still, exceptions could occur if abnormal > "%s" placeholders are found in the translated string). Are there some > utilities in django, to allow a safe string substitution (which might, > for example, simply log an error if a buggy string si found) ? > Python's template strings' "safe_substitute()" won't fit, because it > swallows errors without any notice... I'm not aware of any. I suspect it shouldn't be that difficult to write one, no? > * unknown translatable strings : I have in different data files (eg. > yaml), strings which will need translation, but that can't be detected > by gettext and co, since they only appear in the code as variable i.e > "_(yamlvar)". The easiest, I guess, would be to replace them by > specific tags (like "TR_HOMEPAGE_TITLE"), and to have a tool browse > the code to extract them and add them to the standard gettext > translation chain. Such a tool shouldn't be too hard to code, but I'd > rather know : doesn't such a tool already exist somewhere ? I've seen > no such mention in gettext or babel tools, only recogniztion via > function calls ( _(), tr()... ). I'm not aware of any. > * I have seen nowhere mention of how to remove deprecated/unused > strings from gettext files - only merging translations seems to > interest people. However, having a translation file which slowly fills > itself with outdated data doesn't sound cool to me. Does anyone know > tools/program flags which would list/extract translations that don't > seem used anymore ? makemessages should comment out unused strings. With kind regards, -- Baurzhan Ismagulov http://www.kz-easy.com/ -- 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.
