Den 26. sep. 2006 kl. 10.34 skrev Ross Gardler:
Does this new i18n solution require a ?locale=xx in the URL in any
situations? If so then this is not a good solution. It will break
the static build of the site since "?" is not a valid character in
filenames, Cocoon therefore encodes this which in turn breaks links.
You need to make the language selection part of the url, i.e.
http://foo.com/bar.en.html
or
http://foo.com/en/bar.xml
I can open http://localhost:8888/index.en.html and have my page in
English. The problem with this solution is that it does not work
nicely in a webapp environment (e.g. forrest run), because this
locale encoding does not communicate with the locale modules in
Cocoon (LocaleAction, LocaleMatcher, I18nTransformer). Thus, all
menus and tabs are/will most likely be in a different language. In
addition, it's location in the menu is lost.
The problem with static builds is a known one in that you can't build
all locales in the same run. But my colleague is building the site
just fine, running the CLI once for each locale IIHUC. I'll ask him
to fill in the details/correct me. Thus, it works, although not
optimally.
although I am a little unsure of the impact of the fact that en_US
is defined as the global default language. It could mean that for
that special case you would get the _en version without writing ?
locale=en.
The global language default should be set in a config file.
Agree, I just don't know how to do it.
That is, you can just delete it, and the strings will appear in
English if there's no match. The only benefit of having it there
is to serve as an example for new translations.
And to allow people to override the default settings for those
strings, even in English.
I'm -1 on deleting it for that reason and for the two reasons
(documentation and human readability) that Sjur provides.
That's fine, it does not do any harm having it there. Just rename it
to the correct language code:-)
Sjur
