On 1/27/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On 1/27/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote: > >> Jörn Nettingsmeier wrote: > >> the issue has been solved. > >> my english resource catalog was called cmsui_en.xml. as it turns out, it > >> is assumed to be in the file cmsui.xml, even if english is not the > >> default language of the publication. changing the filename fixed the > >> problem for me. maybe i'm overlooking some subtleties, but iiuc this > >> behaviour is counter-intuitive and needs to be changed. > > > > FYI: > > You can use cmsui.xml or cmsui_en.xml, but you must be consistent. If > > Lenya sees cmsui.xml with the desired language specifier, it will not > > look for cmsui_xx.xml for that language. This is documented (poorly?) > > at: > > http://solprovider.com/lenya/i18nfiles > > your docs say, "The default language files "cmsui.xml" will only be used > when the language is specified and there is no language file." > this is definitely not always the case.
As in my update (we cross-posted), if you can guarantee the language sent to i18n always exists, then the default language file (cmsui.xml) is only used if the language specified in that file is valid. You could change it to something else (not "en", like "xx") and it would still catch the invalid languages. But there is no reason to maintain a fallback lanaguage if it is not a valid language, so either use cmsui.xml for a valid language, or remove it and let invalid languages set everything to "untranslated". A more universal solution is to load the specific language before the default language, so if cmsui_en.xml has an entry, Lenya would use it, but if the entry was missing, it would use cmsui.xml. > i think the problem is that the global file is cmsui.xml, which is > implicitly english, and my publication used cmsui_en.xml. It is explicitly English: xml:lang="en". That is easy to change. > > I prefer the language extension in all filenames. > so do i. You know my site. That is what my instructions recommend. > and i wonder whether the i18n catalogues should be moved. right now, > they are in lenya/resources/i18n, which by current usage means that > system properties are being overridden, i.e. the gui translations. this > does not make sense, because i18n fixes for the gui should be fed back > to the trunk anyway. no publication should need to keep their own i18n > resources for system stuff. > > since most people use it to i18nize their live websites, it would be > much nicer to have the catalogues in resources/i18n. > what do you think? I expect i18n to be improved soon. The current system only supports i18n at the publication and global levels. For modules to be plug-and-play, they need their own i18n files. Templates also need the ability to override i18n. Consider the case where a publication is derived from a template derived from another template that uses global modules. Every module needs its own i18n files. The templates can override those files. The publication can override the templates' files. The search for an i18n key should be: 1. publication module 2. publication 3. template module 4. template 5. parent template module 6. parent template ... (other template inheritance) 7. module 8. global In practice, most would only use the first two and the last two, but the ability to override at any level is important. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
