Description

Since the 1.9 Update in JuraWiki we have trouble with the language settings. On IE and Safari (Mac) you see the navigation in English while the browser settings are on german. On Firefox (Mac) it's OK.

Steps to reproduce

1. In the language settings of IE choose de-DE

2. Load http://www.jurawiki.de

The content is german, but the navigation is in english. For example you will see that the 2nd tab of the main navigation is RecentChanges and not AktuelleÄnderungen. If you load the same page on Firefox, you will see there the correct german term.

Example

Component selection

• general

Details

Workaround

Discussion

I found a solution for the IE. Just add the custom language tag "de" to your user agent and it works.

Beside that IE is stupid, in this case moinmoin could handle it better and also parse de-DE / de-CH / .... correctly to de and also not depend on case sensitivity (DE should also work for de).

When you install a copy of Internet Explorer 7, your preferences are automatically set according to the Windows user locale, although you are given the opportunity to modify this when you first install. Note that, if you haven't customized your browser's language preferences, when you change the Windows user locale the browser preferences get changed too. If you customize the browser settings, they no longer follow the changes in the Windows user locale. (The Windows user locale settings allow you to switch formats, such as which character is used as the decimal separator, the order of date information, etc. by selecting different locales.)

The values sent in the Accept-Language request-header from IE7 are typically of the form language-region. There is typically no language-only form. For example, if you are French your Accept-Language header will present fr-FR to the server.

There are some servers that are unable to match fr-FR against a document labelled on the server as fr. To avoid missing out on French resources from such sites you may want to add the fr as an alternative preference (after the fr-FR). You can do this by clicking on the 'Add' button in the language preferences dialog, and typing fr into the 'Custom' field.

-- MarcelHäfner 2010-09-10 08:46:39

Code from current moin 1.9 repo

def browserLanguages(request):
    """
    Return the accepted languages as set in the user browser.

    Parse the HTTP headers and extract the accepted languages, according to:
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4

    Return a list of languages and base languages - as they are specified in
    the request, normalizing to lower case.
    """
    fallback = []
    accepted = request.accept_languages
    if accepted:
        # Add base language for each sub language. If the user specified
        # a sub language like "en-us", we will try to to provide it or
        # a least the base language "en" in this case.
        for lang, quality in accepted:
            lang = lang.lower()
            fallback.append(lang)
            if '-' in lang:
                baselang = lang.split('-')[0]
                fallback.append(baselang)
    return fallback

Hmm, that code doesn't look like being used. Seems like language init is wrong / missing. Patches are welcome.

For the special case of some wiki running on thinkmo.de (jurawiki, linuxwiki, etc.) there was also a wrong configuration variable used (default_lang was wrong, for 1.9 it must be language_default), so the correct fallback didn't work and it used english. The configuration variable problem there has been fixed.

• that must be it, 'coz now it works with my IE and langauge set to de-CH
• "de" now works on jurawiki.de / linuxwiki.de because I configured it as language_default and so it will be used as fallback - so better test with some other language or on some other wiki

Analysis

This is not a bug, moin is just doing an exact match against what it has.

Note: this is hypothetically assuming that we have no pt-BR (we do have that) just to demonstrate the problem. Giving pt (which is pt-PT in case of moin translations) would be incorrect for someone wanting pt-BR as a native pt-BR speaker told us.

moin 1.8 did some magic by stripping away the -XX country part, but while this works for some cases (like de-DE, de-AT falling back to de then), this can have unwanted consequences if languages aren't compatible (like pt-BR with pt(-PT), or zh-tw with zh(-cn)).

Thus, conclusion is we can't fix that on the server side due to missing "language compatibility informations", users have to configure their browsers correctly and give all language / locale code they find acceptable, in their preferred order. If nothing matches, they'll get language_default.

Fix

Update your browser language preferences:

• if you speak german, you want to have: de-DE, de (and there might be no harm by adding de-AT, de-CH also)
• if you want traditional chinese, you want: zh-TW (and maybe some others you know better than I do)
• if you want simplified chinese, you want: zh, zh-CN (and maybe some others you know better than I do)
• if you want brazilian portuguese, you want: pt-BR
• if you want portuguese (portugal): pt, pt-PT

In general, specify EVERYTHING that you understand well, in order of preference. If you use the short form, you may have to find out what moin is using in that case (for example, pt contains pt-PT content, de contains de-DE content). For most cases, moin will just match on the short form (only exceptions for moin 1.9 are pt-BR and zh-TW).

Plan

• Priority:
• Assigned to:
• Status: no bug, can't be solved server-side

CategoryMoinMoinNoBug