internationalisation - missing strings form i18nformat() function

[hosszu]

Dear Sir,

I find Indico perfect and I already installed it on server. Will be used for managing medical events.

I started with translation to Czech language, which goes very fast, just have a problem.

I followed the documentation, but all strings which are put in i18nformat() function are not extracted to messages.po. All of them are missing. And it is the same situation with french or spanish mutation from indico transifex.

Am I doing something wrong ?

Thank you for your help.

[pferreir]

Hello,

Which Indico version are you using? It is weird, are you using the commands at:

http://indico-software.org/wiki/Dev/i18n#Managingdictionaries

?

[hosszu]

Hello,

my version is 0.98.3.

I have already done some work on it.
so, problem is babel itself, especialy babel.cfg:

it follows one filetype only once. no repeated extraction.
so in original version of babel.cfg

[extractors]
old_strings = indico.util.i18n:extract
[python:**.py]
encoding = utf-8
[mako:**.tpl]
encoding = utf-8
[old_strings:**.py]
encoding = utf-8

the [old_strings:**.py] part is never performed, and never is called the user defined extractor function written for that. Therefore the _() function inside a string, e.g. i18nformat("""_("Registration date") """) is not extracted to messages.po.

if you change the order like this:

[extractors]
old_strings = indico.util.i18n:extract
[old_strings:**.py]
encoding = utf-8
[python:**.py]
encoding = utf-8
[mako:**.tpl]
encoding = utf-8

old:strings part is parsed but there is the [python:**.py] ignored.
that's what I have found by experimenting. (babel 0.9.6, python 2.6.6)

---

unfortunately there is more than 1000 uses of i18nformat("""_("something")""") (calculated as grep "i18nformat".

So to be consistent, what is the purpose and future idea of i18nformat() function ? in source code note says "only used for backward-compatibility".
Can I simply rewrite the code like this: ?

your version: i18nformat("""%s <font color=\"red\">( _("cancelled") )""")%session1
my version: ("""%s <font color=\"red\">( """+_("cancelled")+""" )""")%session1
# this works either with Indico, either with babel default extractor.

is this OK with further development and is such a code rewrite usable for you for next version ?

---

and one more different internalisation question:

how to internationalize Layout/Menu? items ? (Overview, Scientific Programme...etc.)
Giving them a new name, which is written to database is not solution.
the code passes any item name through _() function - so most easy way is to give them names like '_("Overview")' ....
...BUT:

• this will never be extracted by babel (names are stored in database not in code)
• adding it manualy to messages.po is OK and works, but first update_catalog will remove it.
• rewriting displayMgr.py - line 847 from "caption": "Overview", \ to "caption": _("Overview"), \ is not working

What would be the most compatible way for you ? (so that code would be usable for future versions)

---

I know I gave a lot of questions, but please try to answer all of them, so that my code "upgrades" are usable for you.

thank you.

[pferreir]

Hello again,

i18nformat is not supposed to be used anymore. It exists in order to support a pattern that the people who originally wrote Indico's i18n code thought smart but is highly problematic. We are getting rid of it and all new code should just use _() and formatting strings when needed.
Whenever in doubt, please refer to the wiki.

As for the issue with babel.cfg, I will commit a patch that should fix it in a moment. Basically, the extraction function was not working very well...

There is a solution if you want Babel to extract a string even though it may have no use in the code: N_. You can just set it as a marker for translation - it will do nothing besides returning the same string. You can then call _() at a more appropriate time. I agree we should be using it for the menus and other potentially variable pieces of text, but we haven't gone as far as fixing it.

Thanks!

[pferreir]

OK, 9ad698ec90267df4de557e0e52ed19a3ab9c6220 should fix the issue.