zeitgeist team mailing list archive

[Markus Korn <thekorn@xxxxxx>]

I discussed this issue with Siegfried yesterday, and I would like to bring the overall translation workflow to everybody's attention again:
 * We want to make our ontology 'symbols' translatable
 * logging output should not be translated
 * we might need translation support for tools in tools/
 * we should not use lp:zeitgeist as the target branch for launchpad's translation service, we should use another branch, and merge translations as part of the release process.

Any further thoughts?

-- 
I18N of zeitgeist
https://bugs.launchpad.net/bugs/397715
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.

Status in Zeitgeist Framework: Confirmed

Bug description:
zeitgeist is using gettext for I18N in various places, but its usage is inconsistent. A quick grep with `grep -R -E "[^\_]\_{1}\(" .` shows we are using gettext for:
 - some logging messages
 - the name and description of the FF DataProvider
 - display name of Content and Source objects in our datamodel (real gettext support is not implemented yet)

Thinking about this three items a bit I think none of them make sense at all. Logging is for debugging purposes, in the future we will ask our user to add a log file to a bugreport. If the logging messages are translated to a random language we will hardly understand the content. Translating the display name of Content and Source object also makes no sense, instead of this it should be done by the client. This way one database can be accessed with different language settings. And if we agree on the last two arguments, it also makes less sense for the last item.

But just in case I'm missing the point here, and we decide to have I18N support in zeitgeist we should decide which parts we would exactly like to translate, and dig trough the code to add language support to related elements consistently.

Markus