Please add en_NZ "English (New Zealand)" to preferred languages list

Bug #47280 reported by Robert Ancell
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
Medium
Unassigned
language-selector (Ubuntu)
Fix Released
Wishlist
Arne Goetje

Bug Description

Please update the list in: https://launchpad.net/rosetta/prefs

Revision history for this message
Diogo Matsubara (matsubara) wrote :

Hi Robert,

Is en_NZ so different from the other forms of english that it needs another language code? What's your use case to have another language code for en_NZ?
Thanks for the report.

Changed in rosetta:
status: Unconfirmed → Needs Info
Revision history for this message
Robert Ancell (robert-ancell) wrote : Re: [Bug 47280] Re: Please add en_NZ "English (New Zealand)" to preferred languages list

Hi Diogo,

The current Rosetta has entries for Australian and Canadian English
(which are in-between the dominant British and US English spellings).
New Zealand and Australian spelling and formatting I would expect to
be more or less identical and close to the British spelling.

A New Zealand end-user of Ubuntu (or similar) would logically set
their language to en_NZ which would fall back to en. If I translated a
program written natively in US English I would provide en_NZ, en_GB
and en_AU translations otherwise all countries would incorrectly fall
back to en (US English in this case). This is a limitation (at least
in Ubuntu) that gettext does not have a tree of languages (i.e. NZ
users should look for translations in this order: en_NZ -> en_AU ->
en_GB -> en -> C).

I suppose by the same reasoning there should also be an entry in
Rosetta for en_US (US English). As the spelling used in "en" is
undefined a US English speaker would state my software has spelling
mistakes and thus I would encourage them to make an en_US translation
(e.g. colour (NZ, AU, GB) -> color (US)).

Ultimately en_NZ is just as valid as en_AU (the only difference being
the population size). I see that you have tried to keep the list to a
minimum (which I agree with) though this has made it impossible for a
Rosetta user to track the status of a rare translation (such as
en_NZ).

The solutions I see are:
1. Add all the en_* variants - this would make the list very large
2. Make an advanced option to add various rare language codes
3. Change the "English (Australian)" to "English (Australian and New
Zealand)" - i.e. watch en_AU and en_NZ
4. Make four English variants - English (en), British English (en_GB),
US English (en_US), Other English Variants (en_*). Though this would
be annoying if you were notified of all these possible variants.

--Robert

On 17/11/06, Diogo Matsubara <email address hidden> wrote:
> Hi Robert,
>
> Is en_NZ so different from the other forms of english that it needs another language code? What's your use case to have another language code for en_NZ?
> Thanks for the report.
>
> ** Changed in: rosetta (upstream)
> Status: Unconfirmed => Needs Info
>
> --
> Please add en_NZ "English (New Zealand)" to preferred languages list
> https://launchpad.net/bugs/47280
>

Revision history for this message
Данило Шеган (danilo) wrote :

List of 'preferred languages' is a list of languages you are interested in translating into.

US English is standard for most projects (i.e. at least for Gnome[1] and KDE[2]), so there is usually no need for en_US. Reasons for this are multiple, but apart from consistency, it also allows better translation memory reuse (i.e. translators will be able to easily reuse translations from other programs using American English as their base language).

As for other variants, I know en_CA has definitely some different translations and spellings from en_GB, at least in Gnome. I am not sure about en_NZ, but if there's an actual difference from en_AU, then I am perfectly fine with creating it: provided you actually want to provide translations for en_NZ.

If this is only about display (as compared to functionality) preferences, we might want to figure out a way to provide "aliases" between languages.

[1]http://developer.gnome.org/documents/style-guide/grammar.html
[2]http://l10n.kde.org/docs//styleguide/other-consistency-issues.html

Revision history for this message
Robert Ancell (robert-ancell) wrote :

OK I've looked into this and it would seem that the problem lies in the 'language-selector-common' Ubuntu package - it has support for falling back on languages but no English variants have been added to the database.

I would be interested to know if there are any differences between en_AU and en_GB, as I would expect it to have as few differences as en_NZ as thus be just as redundant.

The lack of en_US is fine if all projects follow the "default to US English" policy. I don't know what policy Rosetta has on small projects (especially ones written by non-English speakers which may be unlikely to be US English by default).

It would be useful to state at the bottom of the language list why not all languages are present and what is required to have one added to the list.

I have reported a bug in the Ubuntu language-selector package (#72952) that should hopefully make the en_NZ translation unnecessary except in most cases.

Thanks,
--Robert

Revision history for this message
Robert Ancell (robert-ancell) wrote :

That is en_NZ unnecessary in the _rarest_ cases.

Revision history for this message
George Pollard (porges) wrote :

I've been providing en_NZ translations by manually editing the URL to replace "en_XX" with "en_NZ", which seems to be working*. It would be more useful if I could just click on "en_NZ", however.

* For example: https://translations.launchpad.net/ubuntu/feisty/+lang/en_NZ

Revision history for this message
Carlos Perelló Marín (carlos) wrote :

George, please, stop doing that. Duplicating translations just to workaround a bug on language-selector program is madness.

Btw, the fact that you are able to do that is an implementation detail that will disappear soon (not because you pointed us to it, the developers already agreed on doing that some time ago).

Cheers.

Revision history for this message
George Pollard (porges) wrote :

Oh ok, sorry. I originally just went there to see if there were any translations. I saw that other people were providing translations (puttputt, James Li, &c.), so I thought I would help out.

Now that I know I shouldn’t, I won’t :)

Revision history for this message
Carlos Perelló Marín (carlos) wrote :

This problem will be solved on Ubuntu level, so we don't duplicate translations.

Changed in rosetta:
status: Needs Info → Rejected
Revision history for this message
Данило Шеган (danilo) wrote :

As far as solving this on Ubuntu level, it just needs to set the LANGUAGE variable appropriately to en_NZ:en_AU:en_GB:en or whatever is more suitable.

Daniel T Chen (crimsun)
Changed in language-selector:
importance: Undecided → Wishlist
Revision history for this message
Loïc Minier (lool) wrote :

Currently there are exactly two codes for which we offer multiple choices:
grep '^[^#]' data/languagelist | cut -d\; -f 3 | sed 's/_.*//' | sort | uniq -d
pt
zh

for:
Portuguese (Brazil)
Portuguese
Chinese (China)
Chinese (Hong Kong)
Chinese (Singapore)
Chinese (Taiwan)

These are the locales currently in the -en langpack:
dpkg -L language-pack-en-base | grep /usr/share/locale-langpack | sed -rn 's#.*/([^/]*)/LC_MESSAGES$#\1#p'
en_GB en_AU en_CA en en_NZ en_US en@boldquot en@quot

I think a wider discussion on this topic on ubuntu-devel@ would be good to clarify whether we want to go from one English in the list to 4 or so; I would guess we want to do this for all languages.

My personal opinion is that while it is more complex, we already expose this complexity in ubiquity during installation (albeit assisted).

Revision history for this message
Arne Goetje (arnegoetje) wrote :

What would be the appropriate fallback for en_CA?

Changed in language-selector (Ubuntu):
status: New → Incomplete
assignee: nobody → Arne Goetje (arnegoetje)
Revision history for this message
Robert Ancell (robert-ancell) wrote :

I'm not Canadian but I'd expect en_CA would fall back to en_US..

Revision history for this message
Arne Goetje (arnegoetje) wrote :

Robert Ancell wrote:
> I'm not Canadian but I'd expect en_CA would fall back to en_US..

OK, according to Wikipedia, both spellings, en_US and en_GB are common
in Canada. Therefor I have set the fallback to 'en' for now, means
Generic English, whatever is available.

Thanks
Arne

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package language-selector - 0.4.11

---------------
language-selector (0.4.11) karmic; urgency=low

  * Fix crash in gnome-language-selector (LP: #427716)
  * Fall back to 'en_US' locale if none has been defined or has been set
    to 'C'. (LP: #386029) (LP: #346363) (LP: #347240)
  * Fix crash when ~/.xinput/ is not present (LP: #219218)
  * Add manpage for gnome-language-selector (Thanks to Alex Lourie)
   (LP: #426642)
  * Fix typo in LanguageSelector/FontConfig.py (LP: #219398)
  * data/languagelist: add fallback codes for all English variations we
    have as locales (LP: #47280) (LP: #72952)
  * Update translations from Launchpad
  * Really remove now obsolete Chinese entry from language list
    (LP: #431228)

 -- Arne Goetje <email address hidden> Thu, 17 Sep 2009 22:41:58 +0800

Changed in language-selector (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.