Remember the tokeniser only has to *find* the __(***), so as long as
that exists in a findable class, it will find it - it doesn't have to
make any sense.
It's not the cleanest way, but I tend to write a local __() method
that does not do anything other than return the same value, then if
it's a form message it will be translated and be in my XLIFF files. I
do this for the form errors, but for the labels I just print those in
the template manually anyway. You could even have a helper class
somewhere, and do something like: $widget-
>setLabel(MyDummyI18nHelper::__("My label").
This is not a solution, just a workaround if anyone is reading and
looking for a quick fix.
I agree that it wouldn't be difficult to cache a php file with all the
generated __() strings for all the warnings and messages etc. then
make sure the extract method looks there during the task.
Russ.
On Mar 14, 5:22 am, Tom Boutell <[email protected]> wrote:
> Automatic i18n sounds cool until you actually try to extract those
> labels to create ready-to-fill-out xliff files and/or a web interface
> for translators. There's no clean way to do it, you can't just look
> for __() using the PHP tokenizer as you can do for other strings.
> Which is probably why i18n:extract doesn't even attempt it (it also
> doesn't look at plugins, but that's much more easily overcome).
>
> I wrote a task today called i18n-update that manages to work around
> this by instantiating every form class without constructor arguments,
> rendering the form to a string and then pulling out the label
> elements. But this requires that form classes be designed to at least
> limp along without proper arguments, which is not a good thing if they
> truly should have them. I suppose I could have a static method the
> task uses instead of the regular constructor and do the fakery in the
> static method before calling the regular constructor, call that in
> preference to the constructor if it exists...
>
> My solution also requires that instantiating a form without arguments
> have no undesirable side effects, the form formatter actually use a
> label element, etc. Commonly both of those things are true, but that's
> not enough confidence for a task that could be contributed back to the
> core I think.
>
> One could look for setLabel() calls and the like but there are many
> ways to set a label. It might not even happen in the same class file.
> The halting problem creeps in...
>
> So my point here is this: I hope that in Symfony 2.0 forms this issue
> is reconsidered. I lean toward requiring developers to manually
> provide form labels, or at least not doing automatic I18N of those
> form labels. Either way, we wind up with __() calls that can be
> extracted from the source code in an orderly fashion. Right now you
> can't do __() even if you want to because it leads to a double
> internationalization call.
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
