Hi, yes, the short answer is "it works as designed". If you look up the API reference, you will find that tr takes a *string* as its first argument [1], so you cannot pass arbitrary expressions right now.
But actually, I tend to agree that this would be a useful feature, to allow expressions that would evaluate to a string at run time. It would also suffice for the run time system, as long as the expression evaluates to a valid translation key. I just see two issues here: - tr() is used on two occasions, the second being the before mentioned translation lookup at run time. But the first is during generation (as you found out), when the string literals are extracted as keys for the .po files. An arbitrary expression cannot serve as a key for that, so the generator would have to skip those occurrences of tr() in the source. You, as the developer, would have to provide the translation keys somehow. Either you edit them directly in the .po file (und you have to do that for *each* language you support - tedious). Or you make sure that *all* possible strings this expression can evaluate to during run time, are listed elsewhere as string arguments to tr() calls, so the generator can pick them up as keys. - The other is a minor: The rt translation system uses the given key as a default, in case there is no translation for this key in the given locale. This would still work, but you as the application developer would have no chance of knowing what the fall-back value might look like when you look at the code. If you feel like it, open an enhancement bug in our bug tracker, and add some comment on how you would envision you would provide the missing keys for the .po files. T. [1] http://demo.qooxdoo.org/current/apiviewer/#qx.locale.Manager~tr A.Yerenkow wrote: > Hello all! > I have a dynamic application, which make requests, and show results, in > table, and I have for Column Names such code: > > listFields.push(application.tr(data.listFields[i].label)); > > Yes, I understand that scripts are not telepaths, and can not determine > which string here need to be translated not in runtime. > So, questions: > 1. python generate.py source/translation produce error: > - Processing translation for 2 locales... > !!! Could not extract translation from helper.GuiHelper! > !!! Unsupported param of type variable at line 221 > > and stops. do I need to use "eval". to hid from python fact that I'm > going to use a translation here? > Is this necessary to stop build process if such dynamic translation appear? > > 2. Do dynamic translation supported at all? > > 3. If I'm using "eval", translation works just fine. (Tested with 1 > language yet) > Is this possible to use such code without eval, and "all would just > works"? :) > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
