Oh yeah, right! The errors. Gotta capture the errors too. That's... maybe doable... I could iterate over the validators and ask for them all. I should also be asking the widgets nicely for their labels rather than parsing render() output. We shall see.
Your "throw some __() calls that don't do anything in there" technique is a useful one which I'll keep in mind for anything I can't resolve by instantiating and querying and etc. Thanks. On Sun, Mar 14, 2010 at 2:32 PM, Russ <[email protected]> wrote: > 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 > -- 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
