Language fallback definitions

Under the covers the heavy lifting here seems to be done by ICU’s

ualoc_localizationsToUse

WARNING When looking at Darwin source it’s important to keep ABI compatibility in mind. It’s fine to look at the code to get a better understanding of how things work, but if you encode the fine details of the that implementation into your app then you might break as the system evolves.

IMPORTANT This version of the Darwin source correlates to macOS 10.12, which roughly correlates to iOS 10. I don’t expect a lot of changes here but such things are always possible.

Note The file is encoded as UTF-8, which isn’t rendered well by the Darwin web frontend; I recommend you download the file and open use your favourite text editor to open it as UTF-8.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

thank you Eskimo,

However what you have posted just creates more questions rather than providing any answers 😟

The header just has some examples so Its not the actual fallback rules per se. And as its an example only - there is no reason to think it is accurate. It has at least explained what I have seen and been useful.

There were some references in the header to 'ICU 53' and 'ICU 55'. This led to the unicode website and on there is very similar discussions so its apparent the fallback is probably just based on or built with ICU's fallback.

http://userguide.icu-project.org/locale/resources

http://www.icu-project.org/userguide/design#Resource_Bundle_Inheritance

I'm no expect on ICU but there is one thing that stands out ot me - in their discussion the fallback is always more general. It doesn't mention a sideways en_IN -> en_GB progression.

The source code is here http://bugs.icu-project.org/trac/browser and perhaps I could dig through it and evenutally find the ICU fallback rules but you may have noticed in the header there is a "plus Apple additions" so it may not be any use.

Anyway perhaps I should explain what I am doing and why the interest and see what you would do:

I've been working on something that'll be for 60ish countries. A lot of those countries english isn't the primary language but thats ok. Its related to food and the names of the food vaires in the countires, so I using localizable strings to hold those local variations. seemed reasonable at the time.

* A non-location specific "en" (project base)

* Location specific en_<country> as needed. (this is in line with ICU expections that specific bundles are used if they exist otherwise everything falls back to the general one). I added a few of these and everything was working good.

* I added the UK food localisation (en_GB) and annoyingly everything started falling back to that instead. Obviously en_GB is special, its the mother-tounge

So how do I keep everythng for which there is no local bundle keep using the general "en" project base instead of the specific en_GB? should I be using en_001? It seems to be after en_GB? I really don't want to create 60 en_XX languages just stop everyone using UK localisations - also think of the nightmare setting up the app store! 🙂

FWIW I'm in en_AU, I've setup 6 langauges in my app to cover the main english speakers and am resigned to the fact that everyone not catered for explictly is going to the the UK food names, I was just hoping there was a way to reinstate my non-location specific variant. (which I think, but can't tell for sure, is now not used at all?)

cheers,

Fraser

In terms of food names you’re pretty much stuffed (in the

en_AU

en_US

en_GB

en_US

… you may have noticed in the header there is a "plus Apple additions" so it may not be any use.

True, but keep in mind that the Apple variant of ICU is in Darwin.

I really don't want to create 60 en_XX languages just stop everyone using UK localisations …

Is the problem that big? We’re talking language here, not locale, so there’s only nine English variants to choose from on current iOS (Australia, Canada, India, Ireland, New Zealand, Singapore, South Africa, UK, and US). Given the nature of food names, I would’ve thought that it’d be worth carrying localisations for each of these and, where that’s not the case, falling back to

en_GB

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Eskimo,

"In terms of food names you’re pretty much stuffed because that’s one place where the standard fallbacks make no sense."

ha ha yes I think thats the underlying issue here, using locales to localise food names seems appropirate application of it though?

"Is the problem that big?"

No probably not, the problem is it is mysterious I suppose.

"We’re talking language here, not locale, so there’s only nine English variants to choose from on current iOS (Australia, Canada, India, Ireland, New Zealand, Singapore, South Africa, UK, and US)."

Sure they are the main ones but iOS != my app. I'm not limited to the langues iOS supports.

There are over a hundred en-XX variants / dialects defined

Set your phone to be in Germany, langauge to English

NSLocale.preferredLanguages has: 'en-DE'

and so far I've worked out the fallback order for en-DE seems to be:

en-DE

en-150 (European English)

en-GB

en-001 (International English)

en

So I _could_ optimise for english speakers in Germany if I wanted.

having the rules are very useful, it looks en-150 looks like its going to help me out for europe at least.

Anyway back to the original question - am I right in assuming the fallback rules are currently undocumented?

It would be nice to see that change. 🙂

cheers,

Fraser

am I right in assuming the fallback rules are currently undocumented?

Well, they are certainly not documented at that level of detail.

It would be nice to see that change.

You can file a bug report to request that they be documented, but I’d be surprised if that actually happened. Generally we don’t document the system at this level of detail because things like this change over time. Sometimes those changes are just improvements in the code and data (like CLDR) to more accurately reflect the real world, and sometimes the real world itself changes (the current generation of YouTube-watching children seems to have settled on zee not zed, for example).

If you do file a bug, please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"