Hi, I've done something like this, but with an AJAX approach. The user can select the language he wants to edit and the form adjusts to the selected language. Then I only have to validate that at least one language does exist and adjust the __toString() methods of translated objects to provide language fallback.
It is a little tricky, but it works. If you need more information, I will try to provide some detailed examples. The advantage is, that you don't have to get the language in the form, but rather render only the form, required. Hope, this helps a little. Regards, Christopher. -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Tom Ptacnik Gesendet: Dienstag, 8. Juni 2010 08:54 An: symfony users Betreff: [symfony-users] Managing i18n content for frontend in the backend Hi, I want to tell you my thoughts about managing I18N content in the backend and want to know your opinions. I want to internationalize my frontend app - classic (i18n/ messages.xx.xml + object with I18n behaviour) .. no problem Then I need to manage internationalized objects (News) in the backend. I have attributes: title and content (doctrine - i18n behaviour). I want English, Deutch and Czech language. I need to somehow to display this languages on the form. possibility 1) In the master form use $this->embedI18n(array('en', 'de', 'cs')); .. like in Jobeet example. I don't like this solution because the form is too long. 2 fields for every language. (imagine that I want to add some mor languages, or more internationalized fields ... I thing this is not suitable for me) possibility 2) Show only fields for selected translation. There is some solution here [url1] http://forum.symfony-project.org/index.php/t/16823/ ... I almost like it. I want to do something like this [url1]. For this I can use embedI18n(array('onlyOneSelectedLang')) or mergeForm(xxFormTranslation()) I think I'll go with mergeForm() if I don't hit a snag with something. One thing I dont like on the solution in [url1] is that he use use sf_culture in the sfUser object for selecting languege and sf_default_culture setting. I don't think that is correct, because this stuff is for internationalizing the backend, not for the managing the internationalized content. Am I right? So if I don't want to use sf_culture - I have to figer out how to KNOW which language is selected .. which translation show on the form. I've thought about two solutions 1) store it into the session -> something like sf_culture in sf_user object 2) store in only in the URL ( backend_dev.php/news/1/edit/ edited_lang ) If you have read this till this end and you've some opinion or you have deal with something similar .. tell me how you did it. I want to do this: - Show some tabs-like links for changing the language of the form content (EN, DE, CZ) - Store this selected lang into the session (contentCulture) - On the form show only the fields for the selected lang by mergeForm() function What do you thing abou it? -- 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 users" 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-users?hl=en -- 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 users" 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-users?hl=en
