Closed Bug 1259432 Opened 8 years ago Closed 8 years ago

Use 'ses' for Songhay in iOS

Categories

(Firefox for iOS :: Localization, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: flod, Assigned: flod)

References

Details

We removed Songhay in bug 1259424 because of technical issues. 

Filing a bug to keep track of the status of support for this locale in iOS (issue was reported to Apple).
Axel found this: https://en.wikipedia.org/wiki/Template:Songhay_languages Perhaps if we can nail down which Songhay language this is, and it has an ISO 639-2 code, we can add it back.

Mohomodou, can you guide us here?
Flags: needinfo?(mh)
iOS seems to support the following three:

Koyra Chiini
Koyraboro Senni
Zarmaciine

Needinfo'd myself to find the locale codes for these as used by iOS.
Flags: needinfo?(sarentz)
From Mohomodou:

Then we can use:
Koyraboro Senni ("ses")

Standardized Songhay used in Mali is based on this.

If it's too late this time around, we'll catch up next time. 

Many thanks for your great efforts and all the best, 

Mohomodou
Flags: needinfo?(mh)
Fair enough. The whole issue hinges on how a language is represented. The "ses" code is used in Translatewiki and a Wikitionary. I guess for the same reason. My hunch is that "ses" should work to the extent that it is one of the main codes created for the Songhay idioms. In this regard, it preceded "son" which was created to remedy the fragmentation inherent to multiple locale codes.
Fair enough. The whole issue hinges on how a language is represented. The "ses" code is used in Translatewiki and a Wikitionary. I guess for the same reason. My hunch is that "ses" should work to the extent that it is one of the main codes created for the Songhay idioms. In this regard, it preceded "son" which was created to remedy the fragmentation inherent to multiple locale codes.
I just added Koyraboro Senni to my iPhone as a preferred language and it shows up as "ses"

I think you can just go ahead and rename this locale? And we will pick it up if it is present in shipping_locales.txt
Flags: needinfo?(sarentz) → needinfo?(francesco.lodolo)
We still need to add shipping_locales.txt to v4.0. Given that 'ses' never shipped, we'll need to figure out the sign-off process for it with Jeff and Delphine.
Morphing bug and closing.

Addition will be discussed in bug 1268529.
Assignee: nobody → francesco.lodolo
Status: NEW → RESOLVED
Closed: 8 years ago
Component: General → Localization
Flags: needinfo?(francesco.lodolo)
Resolution: --- → FIXED
Summary: [son] Add Songhay to shipping locales in Firefox for iOS → Use 'ses' for Songhay in iOS
Note taken. Clearly, there are technical issues to be sorted out. The existing code system privileges the identity of dialects, which is fine for dialectology – the documentation of individual forms of a language. There are clear variations within the Songhay language(s). That's a reality that might justify the rejection of the “son” locale for iOS (though  Firefox for desktop has been under “son”) since its first release in 2011. Using “ses” just means that we have to identity the regional form of Songhay being used (Gao dialect), not a generic Songhay. Again, this is understandable but raises other questions: does dialectal identification mean to the localization effort when there are hardly any prospects that individual locales will get teams to do localization?
These open questions about language and dialect are certainly complex. The agenda of code creators here does not seem to match ours – that is having tools in any language form under one name/code (“son”) to help maintain the language as a ecross-border vernacular idiom. [ close this explanatory parenthesis here. It is only meant to highlight the ambiguity of the codes assigned to language and the problematic blockage they can cause.]
(In reply to Mohomodou Houssouba from comment #10)
> does dialectal identification mean to the
> localization effort when there are hardly any prospects that individual
> locales will get teams to do localization?

That would be a question for Apple, and sadly Apple is not Mozilla in terms of transparency. On Desktop we can ship any locale code we want, on Android we have a language switcher to change locale in-app, on iOS we're bound to the locale codes supported by the OS, to the point that you can't submit the app on the Store if the locale is not recognized as valid.
I know and agree with you 100%. On the other hand, I appreciate greatly the leeway we have with Mozilla, in terms of making choices that are sound. Indeed we've had discussions with Apple, IBM, etc. and will pursue these. We have already made a step with "son" being listed as locale code for Songhay in many other databases. Thank you again.
I think the underlying issue is Unicode/CLDR. I found http://unicode.org/cldr/trac/ticket/2553#comment:1 for when it was rejected, and OSes using CLDR to provide APIs will likely reject locales that don't have CLDR support.

We'll face a similar issue in mozilla once we use Intl APIs that rely on cldr data in the background.
Thank you very much for the CLDR link. If one reads in it a comment like "'Songhay'" is primarily a lang of Burkina Faso!", there is certainly much talk and work to be done, and you will be right, NOT here. We'll follow up on this with the CLDR people, knowing that it can be a protracted affair. To be sure, that's not Mozilla's  purview.  

NB:
Songhay is among the "cross-border vehicular languages" recognized by the African Academy of Languages (ACALAN). Most of its speakers like in Niger and Mali, in order of size, with smaller populations in Benin and Burkina Faso.
You need to log in before you can comment on or make changes to this bug.