Just for reference, look at the "i18n policies" section at http://live.gnome.org/GnomeWeb/WebPolicies . This is a totally approved document and the CMS i18n needs to adapt to it. It doesn't cover all the details but it's a solid point to build upon. The details agreed should be introduced at http://live.gnome.org/GnomeWeb/Localization - a page that needs update but specially a maintainer. I'm sure we'll agree on most details quite fast. I'll dig a bit into the URLs translatable or not since Murray is showing an deterministic opposition. On Thu, 2006-11-16 at 11:02 +0100, Gergely Nagy wrote: > * wgo/en/foo/ ; wgo/de/fu/ > - perhaps dismissed?: probably unnecessary complication > - this would (probably) also require IRIs (international URIs) Going for this option makes sense. If we are using semantic URLs is because we want that URLs are meaningful to users. Keeping English words in URLs of non-English pages makes them less meaningful. Going through Murray's concerns: > As well as being generally confusing Confusing to whom? Spanish URLs in Spanish pages are not confusing. > a) The URL of translated versions of pages would change when the > translation changes, breaking the unchanging URL rule. No, the URL of translated pages would change when the original English URL would change. If there was a good reason to make a change in English this reason should be as good for the translated versions. I agree that in general we should avoid changing URLs, but this has nothing to do with translations. > b) It would not be easy to guess the URL of translated versions based > on the English original. Why you want to do that? If you are a user you select the version you want from the language selector in the header. If you are a translator, editor, admin etc you also have access to the pages from the backend, where I guess you can see the links between translated versions of a same page. > How else will people link to specific translations? Guessing URLs by > changing en to de is possibly not ideal, but at least it's possible. To start with, why would you want to link to a specific language? Why not setting link to the general URL and leave the language negotiation to the users? If you really need to set a link to a page in one specific language you can go to the page in English (or the language you are familiar with, select the language you wish at the selector and copy&paste the resulting URL. This might be a bit annoying for you in this specific case, but in exchange we make life easier to all the non-English speakers while browsing the site and linking to URLs they understand. > Guessing a translation, in a language I don't speak, is impossible. Then don't guess. :) Go to the page and select the desired translation in order to pick the URL. > I'm totally against this kind of hack. Apparently this is not a hack but the default behavior of LinguaPlone. > It's not well defined The URL path is as translatable as any other text in the page. Is this going to work also with non-Western encoding? What else do we need to define? > or easily understandable :) Translated URLs are more understandable that untranslated. > and it won't work in the real world. The Plone guys say it's working already. > > therefore, the best choice seems to be: > > * wgo/en/foo/ ; wgo/de/foo/ > - with the addition of wgo/foo/, see below > > > Language negotiation: > --------------------- > While it is very useful if the language is "auto-detected" for the user, > there must be a way to view a page in a specific language, no matter the > settings. > > * proposed language selection priority: > 1) URL > 2) cookie > 3) browser setting > 4) fallback to default (English) > > Auto negotiation: > > I propose that language auto-negotiation happens only on URLs, which do > not include a language identifier. > > If the user visits a "generic" URL (i.e. URL without the lang id), she > should be http-redirected to the negotiated language page (priority as > described above). > > This avoids different kinds of content under the same URL, which would > confuse caching proxies. E.g. the URL wgo/about will not be served in > English or German or French, etc. But wgo/en/about will always be served > in English, and thus can be better cached (until the content itself > changes of course :) > > Note, this implies the URL wgo/about is never actually served, but > always redirected. However, links that want to point to localized > content should reference the "generic" url. Therefore, we could include > a "link to this page" element on every page, pointing to the generic > URL. Perhaps describe this linking policy somewhere on the site. > > Requirement: such redirect must be cheap in plone. > > Manual language selection: > > Every page will include a list of the supported languages, where the > user can manually change language. > > This action should: > - save the preferred language in a cookie > - directly forward the user to the wgo/$lang/... page > > This list could include an "Automatic" option which clears the cookie, > and forwards the user to the "generic" URL. > > Furthermore, each page could include a link: view in my preferred > language (written in the users preferred language!). E.g. John Doe > arrives to a wgo page written in Chinese. "Select langage:" is written > in Chinese, and the dropdown shows "Chinese" written in Chinese, > therefore if he is not familiar with the site, he might not know how to > change the language. > > BTW I'm assuming the language in the selection list appear localized. > (English, Deutsch, etc). All agree? > > Further ideas for the language list: > > The language list could prioritize based on auto-negotiated languages. > E.g. the list could start with "Automatic", then $CookieLanguage, then > $BrowserLanguage, and perhaps also include "Default (English)", followed > by all the other languages, sorted alphabetically. > > I guess the preselected item in the list should be the currently > displayed language. Perhaps this could be moved to the very beginning of > the list. > > The list includes languages in localized form. Problems: > - how is it sorted? > - i want to check the Chinese translation, but > cannot recognize it in the list. > > Yet another issue: if the preferred languages appear on top of the list, > will it also be included in the alphabetical part below? (it probably > should) > > > Error404: > --------- > > What happens, if the requested translation does not exist? > > - display error message? > - redirect to preferred (default?) language? > - both? > - submit bug report? > - invite user to translate? > > What about outdated translations? Is that an error? Offer to show > previous version? Use some heuristics to see how big the change was? > (e.g. original content diff size, or authors can mark changes as minor > or "not affecting translations") Or offer to show the change to the > user? > > Summary, things to agree upon: > > - URL scheme: wgo/$lang/foo > - lang negotiation priority > - the redirecting mechanism from wgo/foo > - language selection list > - translated? > - sorted? > - extra items (automatic, preferred langs)? > - extra items appear also in alphabetical list? > - non-existent translations > > > > Cheers, > Greg > > _______________________________________________ > gnome-web-list mailing list > gnome-web-list gnome org > http://mail.gnome.org/mailman/listinfo/gnome-web-list > -- Quim Gil /// http://desdeamericaconamor.org
Attachment:
signature.asc
Description: This is a digitally signed message part