Translation of report
Franz
is there any special method / guide how to translate report and report
description?
I have translated my report description in BudgetingPlugin by using
message.pot and locale specific *.po file; for implementation, see
https://trac-hacks.org/browser/budgetingplugin/0.12/ticketbudgeting/ticketbudgeting.py#L208
Might this be a practicable way (maybe also for Trac itself)?
I still have a problem, because I've used German words in my SQL
statement (because they are displayed in reports view). I would find
it a poor design if I put this also in my messages.pot - but what
would be the alternative?
Thanks in advance,
Franz
Steffen Hoffmann
Hash: SHA1
Am 11.11.2011 13:33, schrieb Franz:
> Hi,
>
> is there any special method / guide how to translate report and report
> description?
>
> I have translated my report description in BudgetingPlugin [...]
Interesting. I had a quick look. I confess, that I haven't worked much
with the report system before, so I can't be definitive regarding
translations in this part of Trac.
OTOH markup in the following lines will most probably NOT work as you
expect, just because there is no such thing like object/variable
translation in Trac's/Babels gettext methods.
> 769 descr = _(report[2])
> 775 sql += " VALUES(%s, null, '%s', '%s', '%s');" % (report[0],
_(report[1]), report[3], descr)
As a side-note: Following PEP8 you should shorten lines for better
commenting/diff/editing experience.
> Might this be a practicable way (maybe also for Trac itself)?
>
> I still have a problem, because I've used German words in my SQL
> statement (because they are displayed in reports view). I would find
> it a poor design if I put this also in my messages.pot - but what
> would be the alternative?
None right now. There is no support in Trac core right now, apart from
standard fields. Any custom field label can't be translated. A plugin
offers at least the possibility by binding an additional message
catalog, but to make it really work, you'd have to translate the SQL
statement on every request. This collides with saving fixed query
strings in the report Trac db table.
Adding variables or translation markup into SQL statement would most
likely be too much to configure for even advanced admins. Translations
are always less flexible, because they can't be changed as quickly as
the report SQL statement. This is a serious conflict. Runtime-changeable
message catalogs are not invented AFAIK, so there's not much hope for
progress either.
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6+iQoACgkQ31DJeiZFuHfaLACgqRlrSAra3EaFrejL6VgF9bMb
YdEAnAp6UVzy9QJPh06fr/ipI4CWKnpl
=/tsn
-----END PGP SIGNATURE-----
Franz
On 12 Nov., 15:56, Steffen Hoffmann <hoff...@web.de> wrote:
> OTOH markup in the following lines will most probably NOT work as you
> expect, just because there is no such thing like object/variable
> translation in Trac's/Babels gettext methods.
>
> > 769 descr = _(report[2])
> > 775 sql += " VALUES(%s, null, '%s', '%s', '%s');" % (report[0],
>
> _(report[1]), report[3], descr)
instance of Trac is using it.
> As a side-note: Following PEP8 you should shorten lines for better
> commenting/diff/editing experience.
sorry for the hassle. BTW: is there any short cut to get it in PEP8
(we are using PyDev)?
> None right now. There is no support in Trac core right now, apart from
> standard fields. Any custom field label can't be translated. A plugin
> offers at least the possibility by binding an additional message
> catalog, but to make it really work, you'd have to translate the SQL
> statement on every request. This collides with saving fixed query
> strings in the report Trac db table.
should be default? Thus the report will be shown in the default
language. I don't know exact figures, but I would assume, that many
Trac installations will be used just in one language.
Regards, Franz
Steffen Hoffmann
Hash: SHA1
On 15.11.2011 12:55, wrote Franz:
> Hi Steffen,
>
> On 12 Nov., 15:56, Steffen Hoffmann <hoff...@web.de> wrote:
>> OTOH markup in the following lines will most probably NOT work as you
>> expect, ...
>>
>> _(report[1]), report[3], descr)
>
> Well, actually this works, as it is commited in the plugin and our
> instance of Trac is using it.
Really? Once I thought the same, but got corrected, because the code
switched to on language (German) only, so dynamically switching at the
client didn't work at all.
>> As a side-note: Following PEP8 you should shorten lines for better
>> commenting/diff/editing experience.
>
> I know, but my collegue and me programmed this before we knew PEP8;
> sorry for the hassle. BTW: is there any short cut to get it in PEP8
> (we are using PyDev)?
I heard of some scripts to accomplish automatic re-formatting for Python
scripts, but forgot, what it was, sorry.
>> None right now. There is no support in Trac core right now, ...
>
> But wouldn't it be a step forward to decide the admin which language
> should be default? Thus the report will be shown in the default
> language. I don't know exact figures, but I would assume, that many
> Trac installations will be used just in one language.
Since Trac 0.12 with still incomplete, but quite strong i18n support
anything like hard-coded language is a step backwards. Doing a
pseudo-translation is just fine for on application. But an development
and project environment should give the freedom to the user.
OT: I know, this is a silent, but truly controversial subject. While
some developers don't care at all ("professional world it's all English
anyway") the rest of the world loves you, and in rare cases even
heartily supports you for just doing i18n without false compromise.
Even, if you personally don't care about Chinese, Hebrew, Russian or
Japanese, just to name some. Fact remains that you can, or should be
able to switch seamlessly. And you should never allow yourself to go
with less. At least aim at what is technically possible. :-)
That's what I see as one of the strong points for Trac as a professional
tool. Be best in class by respecting things like inter-interoperability
and localization. I.e. without (German) localization my applications
would have never taken off and been able to fly as they do these days.
Users especially love the low-fuss, clear UI and features-on-demand (not
per default) as in many other products today.
Sincerely,
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7HrcwACgkQ31DJeiZFuHeh5QCdGIadWQkcHYQAEOkHrrcxC32b
No8An3huf/UXFnAdFDapBChSizkaA0wL
=w5Wn
-----END PGP SIGNATURE-----
Steffen Hoffmann
Hash: SHA1
On 19.11.2011 14:23, wrote Steffen Hoffmann:
> On 15.11.2011 12:55, wrote Franz:
>> On 12 Nov., 15:56, Steffen Hoffmann <hoff...@web.de> wrote:
> I heard of some scripts to accomplish automatic re-formatting for Python
> scripts, but forgot, what it was, sorry.
Just found one: pylint - http://www.logilab.org/857
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7HvfkACgkQ31DJeiZFuHf11wCffNmpNB2WutK0GBK7rFNK+u0k
KlkAn1un2d51zEkP6JwhrIikqYQnauU7
=gn1n
-----END PGP SIGNATURE-----
Franz
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15.11.2011 12:55, wrote Franz:
>
> > Hi Steffen,
>
> > On 12 Nov., 15:56, Steffen Hoffmann <hoff...@web.de> wrote:
> >> OTOH markup in the following lines will most probably NOT work as you
> >> expect, ...
>
> >> _(report[1]), report[3], descr)
>
> > Well, actually this works, as it is commited in the plugin and our
> > instance of Trac is using it.
>
> Really? Once I thought the same, but got corrected, because the code
> switched to on language (German) only, so dynamically switching at the
> client didn't work at all.
It only work once (when installing); so you when using an English
system it should installed the English description, when using a
German system it should use the German description.
> >> None right now. There is no support in Trac core right now, ...
>
> > But wouldn't it be a step forward to decide the admin which language
> > should be default? Thus the report will be shown in the default
> > language. I don't know exact figures, but I would assume, that many
> > Trac installations will be used just in one language.
>
> Since Trac 0.12 with still incomplete, but quite strong i18n support
> anything like hard-coded language is a step backwards. Doing a
> pseudo-translation is just fine for on application. But an development
> and project environment should give the freedom to the user.
I agree, that it would be best if it would be configurable by user. Is
there already a ticket or discussion page for this issue on the Trac
page?
>
> Sincerely,
>
> Steffen Hoffmann
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
Steffen Hoffmann
Hash: SHA1
On 21.11.2011 08:17, wrote Franz:
>> On 19 Nov., 14:23, Steffen Hoffmann <hoff...@web.de> wrote: ...
>> Really? Once I thought the same, but got corrected, because the
>> code switched to on language (German) only, so dynamically
>> switching at the client didn't work at all.
>>
> It only work once (when installing); so you when using an English
> system it should installed the English description, when using a
> German system it should use the German description.
Expected, still relief for my mind to hear that.
> ... I agree, that it would be best if it would be configurable by
> user. Is there already a ticket or discussion page for this issue on
> the Trac page?
Well, at least there is #10339 [1]. It's quite fresh, but I'm still
mildly surprised that it exists at all, not seen that before.
Sincerely,
Steffen Hoffmann
[1] http://trac.edgewall.org/ticket/10339
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7KqNoACgkQ31DJeiZFuHesjgCgyEUEBaBZrgky9A4KVd1nSQY5
jL4AoIWrgvYWKTtpzOy4swiiqdSJlmYu
=k4oy
-----END PGP SIGNATURE-----