I'm closing this bug since it isn't really being useful anymore. The
current status is that only the --help output is translated, and
translations done on Launchpad (for the three help strings) are
automatically pushed to a separate branch from where we can incorporate

I think it'd make sense to translate "normal" log output ("Starting...",
"Already running...", etc.) but before that we should fix the log output
to actually be readable. All those date stamps and stuff that's
currently in the output is way too verbose that people would bother to
read it at all (although it does make sense to have that in the log
file), so we should figure out what to do with that and then we may make
more strings translatable. We can open a separate bug for that once
we're going to work on it.

On the other side there's the ontology translation topic. At the moment
the ontology strings are being used (in fact, nowadays we're lacking
display strings for the ontology). If that changes later we should make
them translatable, but we don't need this bug to remember us of that.

** Changed in: zeitgeist
       Status: Confirmed => Fix Released

You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.

  I18N of zeitgeist

Status in Zeitgeist Framework:
  Fix Released

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.


Mailing list: https://launchpad.net/~zeitgeist
Post to     : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Reply via email to