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
