Feature Proposal: Simple convenient language switching should work

It seems to be completely wrong that the "Change language" feature should have the lowest prority. This means that if the preferred language is set for a site or user, as it described inUserInterfaceInternationalisation, then this feature will be be hardly broken. "Language detection" part of this topic should be corrected as follows.

• If the supported language has been selected with the LanguageSelector, then the selected value should be used in any context of the current Web session if this language supported.
• Else the user preferred languages list to be constructed by concatenation if the LANGUAGE variable value in a user personal topic preference and the Accept-Language sent by the browser: (the browser settings reflect language priorities to the user but the priorities may differ for sites, so the personal topic should have precedence).
  • The first supported language of the list, which is also listed in the LANGUAGE variable which to be set as a web (or TWiki) preference used if exists
  • The first supported language of the list used if the LANGUAGE variable unset as a web preference.
  • Otherwise the user preferred languages list contains no supported languages to be listed in the existing LANGUAGE variable for a web, then the first value of LANGUAGE variable as a web or TWiki preference (or en=English if LANGUAGE is unset for a web) should be used because user can easy override it on a session base via LanguageSelector or ask admin to append or unset web level LANGUAGE preference.

It seems to be very important to correct core and plugins to match exactly this (or better appropriate) language selection scheme to be described in this(?) topic . The language support looks to be broken if different languages mixed in the screen from site with full information in all languages. The language selection should be done simultaneously for interface and topics in core and plugins. As far as mail notifications can not check language used for last WebNotify changes, they should check the preferences in the same manner.

I suggest to extend TWiki::I18N->language() method to do this work. Now it works without arguments and it should keep the same behavior for compatibility if no argument is given. But if it is called with language tag list as an argument, it should return the best for current user choice from this list. The list may contain languages without interface translation. So, users will probably be able to use TopicTranslationsPlugin and translate most valuable topics to/from generally unsupported languages with covenient foreign languages interfaces (such as Russian for most people from former Soviet Union).

-- SergejZnamenskij - 26 Jan 2007