|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
Best pratice splitting up language files?Hi
just started learning the zf a couple of weeks ago, i reached the zend_translate witch i have a few "best pratice" questions about. if i were to build a multilanguage webpage, and lets say i choose the simple array adapter. I dont know much about how the php-engine works in the backscene but my guess would be loading a language file containing all my language strings for all my views / validators etc for each request, would be bad pratice ? wouldnt it be better to somehow split the language file into controller -specific files so that each controller had a language file of its own?.. The only info i could find was if my language file gets too big i should go for another adapter? but changing to another adapter wouldnt change the fact that i was loading tons of language string i wouldnt need for the request?. im sure there is a logic explaination, but i cant seem to find it in eny of the guides / articles on the net. - Mads Lee Jensen |
|
|
Re: Best pratice splitting up language files?Lee,
Simply use the module approach. Split your translation files per module. But keep in mind that this also means that you double your translations if the same wording has to be available in several modules. Also keep in mind that having a array file with over 5000 arrays is a pain. If you expect to have such a amount you should really use a professional adapter like gettext / tmx or equivalent. Use File Searching for adding the translations. Add only the language you need and your user requests... there is no need to add all 100 languages (if you provide them) as your user needs only 1 and your need 1 so maximum 2 languages are needed per request. Use Caching, see performance within the manual. Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com ----- Original Message ----- From: "Mads Lee Jensen" <mads@...> To: <fw-i18n@...> Sent: Monday, June 09, 2008 9:52 PM Subject: [fw-i18n] Best pratice splitting up language files? > > Hi > just started learning the zf a couple of weeks ago, i reached the > zend_translate witch i have a few "best pratice" questions about. > > if i were to build a multilanguage webpage, and lets say i choose the > simple > array adapter. > I dont know much about how the php-engine works in the backscene but my > guess would be loading a language file containing all my language strings > for all my views / validators etc for each request, would be bad pratice ? > wouldnt it be better to somehow split the language file into controller > -specific files so that each controller had a language file of its own?.. > > The only info i could find was if my language file gets too big i should > go > for another adapter? but changing to another adapter wouldnt change the > fact > that i was loading tons of language string i wouldnt need for the > request?. > > im sure there is a logic explaination, but i cant seem to find it in eny > of > the guides / articles on the net. > > - Mads Lee Jensen > -- > View this message in context: > http://www.nabble.com/Best-pratice-splitting-up-language-files--tp17740368p17740368.html > Sent from the Zend I18N/Locale mailing list archive at Nabble.com. |
|
|
Re: Best pratice splitting up language files?Thanks for the reply,
i can see that structuring the language files to modules can remove some of the unneeded language strings, but as you said yourself, i might need to write the same translation multiple times in each module-language-file. Then i thought would it be bad pratice to create a plugin for my frontcontroller running on dispatchLoopStartup() witch will try to find the requested language from either a saved session or GET-param or a zend_locale()->getLanguage() . And instantiate zend_translate, kind of prototype who will load some "global" language strings (default-language-file), plus loading the specific module-language-file, and then save the instance to my registry. in my action controllers i could then grab it, and pass it to my view, and that way avoid the need to type shared language strings multiple times, just put it in my default-language-file? - Mads Lee Jensen |
|
|
Re: Best pratice splitting up language files?It seems to me as if you want to duplicate existing code.
Use Zend_Locale, it detects and selects the language automatically. Use it as parameter to Zend_Translate. Load all used modules and registry them. If you load modules with each request any cache would be nonsense. Beside: All depends on the ammount of translations. If you use only 2000-5000 translations forget all and use a single translation file. :-) Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com ----- Original Message ----- From: "Mads Lee Jensen" <mads@...> To: <fw-i18n@...> Sent: Tuesday, June 10, 2008 9:15 PM Subject: Re: [fw-i18n] Best pratice splitting up language files? > > Thanks for the reply, > i can see that structuring the language files to modules can remove some > of > the unneeded language strings, but as you said yourself, i might need to > write the same translation multiple times in each module-language-file. > > Then i thought would it be bad pratice to create a plugin for my > frontcontroller running on dispatchLoopStartup() witch will try to find > the > requested language from either a saved session or GET-param or a > zend_locale()->getLanguage() . > And instantiate zend_translate, kind of prototype who will load some > "global" language strings (default-language-file), plus loading the > specific > module-language-file, and then save the instance to my registry. > in my action controllers i could then grab it, and pass it to my view, > and that way avoid the need to type shared language strings multiple > times, > just put it in my default-language-file? > > - Mads Lee Jensen > > > -- > View this message in context: > http://www.nabble.com/Best-pratice-splitting-up-language-files--tp17740368p17762650.html > Sent from the Zend I18N/Locale mailing list archive at Nabble.com. |
| Free Forum Powered by Nabble | Forum Help |