Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#14467 closed defect (bug) (fixed)

Localisation not acknowledged by upgrade page.

Reported by: alhadis's profile Alhadis Owned by:
Milestone: 3.1 Priority: normal
Severity: trivial Version: 3.0
Component: Administration Keywords: English, Internationalisation, i18n, American, Language, needs-patch
Focuses: Cc:

Description

This continues to bug me; as an Australian, my WordPress installs are all configured with language settings of "en-AU", but WordPress doesn't seem to interpret it correctly as English:

"You are about to install WordPress 3.0.1 in English. There is a chance this upgrade will break your translation. You may prefer to wait for the localized (localised) version to be released."

This is only a very minor issue, but I still feel insulted that the Americans don't consider Australian English to be the same language. :)

Change History (6)

#1 @nacin
14 years ago

  • Milestone changed from Awaiting Review to 3.1

We account for en_GB I think, but not en_AU. Might as well include ya'll too. :)

#2 @nacin
14 years ago

Hmm, I was thinking about mu_dropdown_languages() apparently.

Still doesn't seem like a bad idea to whitelist our British and Australian friends. On the other hand, if you're running an English localization (which I imagine most don't bother doing?), isn't it important to know you're not updating to the same language pack? Especially with these variants, you might not realize right away that you're not running the localization you downloaded.

#3 @Alhadis
14 years ago

Well, I think instead of making an arbitrary whitelist, it's probably better to adhere to the specifications of the IETF Language Tag:

http://en.wikipedia.org/wiki/IETF_language_tag

http://tools.ietf.org/rfc/bcp/bcp47.txt

As you can see, it's material we're all mostly familiar with:
aa_BB (AA = Language Subtab, BB = Region Subtag).

I think a match for anything that's en_[RECOGNISED_REGIONAL_SUBTAG]) is enough to accommodate for being English.)

In any case, the underlying issue is that WordPress wasn't dropping the regional tag from the language code to ascertain the installation's language.

#4 @dd32
14 years ago

First up, We don't have any "official" translations of WordPress in GB/AU English anyway.

I think a match for anything that's en_[RECOGNISED_REGIONAL_SUBTAG]) is enough to accommodate for being English.)

Which is not what the block is trying to do, The Block of code in question is warning you, that you're not running the 'en_US' localisation, the "official" language of WordPress. Simply accepting en_* as "English" and not displaying that warning would be lying, If you're running a different language setting, then you (should be) using a different language pack, and upgrading will override the current language pack (Even if you're currently in "English")

Perhaps the crux of the problem here is 2 fold

  • WordPress's string is Americanised, Its assumed that "English" === "American English", which as all us Aussies know, that ain't the case ;)
  • You're using a different LANG var without actually using its purpose, which is, to load a different language pack

#5 @jane
14 years ago

  • Keywords needs-patch added

If someone wants to do something about this for 3.1, it needs a patch to be posted now, or be punted to 3.2.

#6 @markjaquith
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [16427]) Make clear that we are installing the *American* English version, so this message makes sense for non-American English translation users. fixes #14467

Note: See TracTickets for help on using tickets.