I18N of zeitgeist

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

2009/7/10 Markus Korn :
> - some logging messages

Maybe you're right here.

> - 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)

Note that the "display name" and the "description" isn't stored in the
database, it's only there at runtime. So having them translates makes
sense as this way Zeitgeist can send them out translated and the GUI
can show them directly (it's not possible to translate all of those
names on the GUI as it doesn't know what they will be -especially for
the data providers- and, in any case, it'd be a duplication of
translation effort).

But yes, translations do need more care and we need to agree on what
to translate exactly.

- --
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBCAAGBQJKVzPkAAoJEBz8IvM2PerjBSYH/2V1SwAOE0mnPI5y8MY6ZY9g
rII3FhV2SpWWuSBAycMHgQdW7LHe0dOp1aJ2NuVUJrCwIlwTEcYb4z5QBxbvCGv3
zqqREugPhbM8OAC3/kKfN7NnerIrPsRxFbOd3F97TNulSkOWzBgtF7BiJOQN/u8q
WyeT40eTmw9WhUvzcwtDWXMniQIRHD2/KKZ0/LgYAPYy22+KBD12AC1Clq34DLfc
IxbyPBIKxMsqkIabqkNO9+mb+J3dfjA/osGslXYUKQxskmdxuQg08KpPyNLHEiyF
4HOFYTr60Ki+i/jkCjUFj6GUNZ817DeqTel7R4vSZXgUDrE+IwDsAFMGbqdovuE=
=w/hK
-----END PGP SIGNATURE-----

Most of our messages are logging and debug messages that in my opinion should not be even translated.
Manifestation and Interpretation are part of an ontology and our own set of rules and conventions that should be translated by apps however not by us. Correct me if I am wrong please so we can clarify the status of this bug.

2009/11/25 Seif Lotfy <email address hidden>:
> Manifestation and Interpretation are part of an ontology and our own set of rules and conventions that should be translated by apps however not by us.

No, the public Python API exposes manifestations and interpretations
and has a user-readable name an description for each, so that should
be translated.

I agree with Siegfried. It will be very convenient for apps if the display_name of Categories (Interp. and Manif.) af translated

Shall we start on that?

Thinks changed alot since this bug was reported, e.g. we are loading the symbols from our ontology. This ontology is entirely untranslated. We need a smart way to translate the ontology. Can this be done in the definition of the ontology itself?

I think there should be a translation to some ontology stuff. Makes no sense to translate our debug messages. As Markus said if we want to fix stuff we will need the debug output readable.

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?

+1 the transaltions happening in trunk are annoying as hell

On Mon, Sep 20, 2010 at 9:57 AM, Markus Korn <email address hidden> wrote:

> 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 subscribed to The
> Zeitgeist Project.
>
> 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
>
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

One part of this bug, not using lp:zeitgeist as target branch for translations, has been fixed, but there are still some issues with i18n in zeitgeist, as mentioned in the description and in one of my last comments.

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 them.

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.