Work around translation key discovery of generator.py

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Work around translation key discovery of generator.py

George Nikolaidis
Dear all,

In a number of cases we have stumbled upon a shortcoming of the
translation framework. It is my understanding that generator.py scans
class files  for tr*() and marktr() calls in order to extract relevant
translation message ids. It then looks up these ids in the .po files to
compile the final JS file.

While this behavior is generally fine, there a lot of cases where we
need to include message ids that do not appear in class files, the most
prominent being:

- message ids that are dynamically generated by adding a prefix to a
server response
- messages appearing in XML files that are parsed at runtime (Qookery)
- message ids as values of static maps that are lazily replaced by their
translation only on first use at runtime

Right now we resort to workarounds such as:

__uglyHackForQooxdooAggressiveTranslationOptimization: function() {
    // TODO There must be a better way to achieve this!
    this.marktr("waffle.common.code.gender.M");
    this.marktr("waffle.common.code.gender.F");
}

Is there a better way to achieve this?

An option in generator.py that includes all .po file content regardless
of message id existence would be perfect.


--
George Nikolaidis ([hidden email])
MEng, MSc Information Systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ergobyte Informatics S.A.
Innovative Software Development
21 Aristotelous str., 54624 Thessaloniki, Greece
Tel: +302310288434, Fax: +302310288134
Website:www.ergobyte.gr


------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Work around translation key discovery of generator.py

Cajus Pollmeier
I'm not sure if I understand the problem correctly. Here's what we do in
an application with the need for dynamic localization:

We're loading i18n messages from a backend and feed them into the
current translation using the "addTranslation" method of
qx.locale.Manager.

The code hasn't been updated for years, but you can basically see it
here:

https://github.com/gonicus/gosa/blob/master/source/class/gosa/Application.js#L211

Maybe it helps.

Cheers,
Cajus

Am Dienstag, den 14.04.2015, 13:18 +0300 schrieb George Nikolaidis:

> Dear all,
>
> In a number of cases we have stumbled upon a shortcoming of the
> translation framework. It is my understanding that generator.py scans
> class files  for tr*() and marktr() calls in order to extract relevant
> translation message ids. It then looks up these ids in the .po files to
> compile the final JS file.
>
> While this behavior is generally fine, there a lot of cases where we
> need to include message ids that do not appear in class files, the most
> prominent being:
>
> - message ids that are dynamically generated by adding a prefix to a
> server response
> - messages appearing in XML files that are parsed at runtime (Qookery)
> - message ids as values of static maps that are lazily replaced by their
> translation only on first use at runtime
>
> Right now we resort to workarounds such as:
>
> __uglyHackForQooxdooAggressiveTranslationOptimization: function() {
>     // TODO There must be a better way to achieve this!
>     this.marktr("waffle.common.code.gender.M");
>     this.marktr("waffle.common.code.gender.F");
> }
>
> Is there a better way to achieve this?
>
> An option in generator.py that includes all .po file content regardless
> of message id existence would be perfect.
>
>

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

signature.asc (180 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Work around translation key discovery of generator.py

Romeo Kenfack Tsakem
Hi Nikolaidis,

qooxdoo does not have a built-in way to handle dynamic translations.
The workaround you are using is one way to deal with that issue. An optimization
would be to define a class with your translation ids in the "defer" function.

You might also use the solution provided by Cajus


Regards,
Romeo

-----Ursprüngliche Nachricht-----
Von: Cajus Pollmeier [mailto:[hidden email]]
Gesendet: Dienstag, 14. April 2015 14:37
An: qooxdoo Development
Betreff: Re: [qooxdoo-devel] Work around translation key discovery of generator.py

I'm not sure if I understand the problem correctly. Here's what we do in an application with the need for dynamic localization:

We're loading i18n messages from a backend and feed them into the current translation using the "addTranslation" method of qx.locale.Manager.

The code hasn't been updated for years, but you can basically see it
here:

https://github.com/gonicus/gosa/blob/master/source/class/gosa/Application.js#L211

Maybe it helps.

Cheers,
Cajus

Am Dienstag, den 14.04.2015, 13:18 +0300 schrieb George Nikolaidis:

> Dear all,
>
> In a number of cases we have stumbled upon a shortcoming of the
> translation framework. It is my understanding that generator.py scans
> class files  for tr*() and marktr() calls in order to extract relevant
> translation message ids. It then looks up these ids in the .po files
> to compile the final JS file.
>
> While this behavior is generally fine, there a lot of cases where we
> need to include message ids that do not appear in class files, the
> most prominent being:
>
> - message ids that are dynamically generated by adding a prefix to a
> server response
> - messages appearing in XML files that are parsed at runtime (Qookery)
> - message ids as values of static maps that are lazily replaced by
> their translation only on first use at runtime
>
> Right now we resort to workarounds such as:
>
> __uglyHackForQooxdooAggressiveTranslationOptimization: function() {
>     // TODO There must be a better way to achieve this!
>     this.marktr("waffle.common.code.gender.M");
>     this.marktr("waffle.common.code.gender.F");
> }
>
> Is there a better way to achieve this?
>
> An option in generator.py that includes all .po file content
> regardless of message id existence would be perfect.
>
>

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Work around translation key discovery of generator.py

George Nikolaidis
Dear Cajus and Romeo,

Thank you for your help. We will put both your suggestions into
practice, that is a. increase our usage of addTranslation() whenever
possible and b. fallback to marktr(), as optimized in the defer part of
a separate class.

Do you believe that filling a feature request in Bugzilla for

> An option in generator.py that includes all .po file content regardless
> of message id existence


will get some attention from the QX developers? It might be easy to
integrate in the rewrite of generate.py.

Regards,
George



On 14/04/2015 04:22 μμ, Romeo Kenfack Tsakem wrote:

> Hi Nikolaidis,
>
> qooxdoo does not have a built-in way to handle dynamic translations.
> The workaround you are using is one way to deal with that issue. An optimization
> would be to define a class with your translation ids in the "defer" function.
>
> You might also use the solution provided by Cajus
>
>
> Regards,
> Romeo
>
> -----Ursprüngliche Nachricht-----
> Von: Cajus Pollmeier [mailto:[hidden email]]
> Gesendet: Dienstag, 14. April 2015 14:37
> An: qooxdoo Development
> Betreff: Re: [qooxdoo-devel] Work around translation key discovery of generator.py
>
> I'm not sure if I understand the problem correctly. Here's what we do in an application with the need for dynamic localization:
>
> We're loading i18n messages from a backend and feed them into the current translation using the "addTranslation" method of qx.locale.Manager.
>
> The code hasn't been updated for years, but you can basically see it
> here:
>
> https://github.com/gonicus/gosa/blob/master/source/class/gosa/Application.js#L211
>
> Maybe it helps.
>
> Cheers,
> Cajus
>

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel