English Name : N'ko unicode range : U+07C0–U+07FF ISO_639-2 : man or nqo ISO_3166-1 : ? (used in gn, ml, sn, ci, gm) Microsoft ID : not available RTL : yes own digits : yes N'ko is a script and STANDARD language. Its purpose is to merge dialects like bambara, mandingo, dioula ... in a one STANDARD language. The difference between these languages is like the difference between english spoken in USA and english spoken in England. N'ko is used in guinea (gn), mali (ml), senegal (sn), ci (ivory coast), gm (gambia), burkina faso (bf). So, it is quite difficult to choose an ISO 3166-1 code.
This needs to be differentiated between 'nqo' and other languages mentioned. While 'nqo' is a distinct language code, 'man' is a so-called (in ISO 639) macrolanguage code encompassing several languages. We usually do not introduce such macrolanguage codes anymore because they do not allow for differentiated attribution, for example if spelling differed between languages the spell-checker could not be told to check for a specific language. As for the 'GN' ISO 3166 code to form a default locale with a language we assign the default country code as lined out by the Ethnologue, in this case http://www.ethnologue.com/language/nqo
On the one part , use nqo is perfect as N'ko ISO_639-2. Even Firefox uses this code for N'ko. On the other part, add a country code could "complicate" the localization. First, the persons which are going to localize come from guinea, mali , senegal. Second, the aim of N'ko is to standardize Mande languages, so to remove/eradicate the fews differences between these languages. Could you just keep nqo ?
(In reply to comment #2) > add a country code could "complicate" the localization. No, sorry, I may have been too short on this.. the country code would only be added for the underlying locale and locale data that always is country dependent, i.e. currency used, separators, date formats, ... The UI translation would only use 'nqo' and if a locale for example nqo_GN asks for the corresponding UI localization there is a fallback mechanism that picks 'nqo' if 'nqo-GN' is not available. Translators would only translate for the 'nqo' language and not have to care about the locale. This is done for most languages, e.g. German 'de' translation is used with de-DE, de-AT and de-CH locales.
ok, I understand now. That's fine. So, let's go for nqo-GN
*** Bug 64404 has been marked as a duplicate of this bug. ***
Didn't see this one, had opened another one but now marked it as duplicate. However, there one thing I'm carrying over which I think is useful: I'm not sure if the feature exists in LO but the Mozilla Pootle server has a function where commonly used special characters can be added so the show in the translation UI. Kairaba has found this useful, so if that's possible, adding the following would be great: ߐߏߎߍߌߋߊߙߘߗߖߕߔߓߡߟߞߝߜߛߚߒߦߥߤߣߢߨߩߪ߲߫߬߭߮߯߰߱߳ߴߵ߷߸߹ߺ߶߀߁߂߃߄߅߆߇߈߉
@Michael: This bug here is about adding the necessary pieces to the LibreOffice code base. There's nothing I could do about any Pootle feature.
I think you misunderstood me or I wasn't clear :) I'm not asking for a *new* Pootle feature, as far as I know, it's part of Pootle by default (see this slightly out of date page http://docs.translatehouse.org/projects/pootle/en/2.5.0-rc1/features/characters.html) For example on the Locamotion Pootle server if I navigate to ADMIN > Languages, there is a field for Special Characters. All I have to do is copy them in and they will appear to the editors of that language. It *may* be that that's a feature only available on Locamotion but the documentation suggests it exists for all, so it would just be a case of copy and paste. I'll ask Dwayne to chip it.
Dwayne just informed me that this used to be a per-server feature but that it will be included in future versions of Pootle so it's not currently an option so please ignore for now.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=99bd42d8e6a239c5365a5487b3d1fea76d84a561 added N'ko [nqo-GN] to language list, fdo#64331 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
did you plan to add N'ko in libreoffice Pootle interface ?
I'm not responsible for any Pootle related things, please ask on the l10n mailing list. AFAIK usually it is Andras who adds new languages.
I've just added the language to Pootle. Also added the special chars that Michael mentioned. And made Kairaba the language admin.
In N'ko, we have our own digits. Here are the n'ko digits : ߀ ߁ ߂ ߃ ߄ ߅ ߆ ߇ ߈ ߉ Is it posible to replace the latin digits by the above n'ko digits ? I know that fix that might be complicated because of "%d", "%f".... PS : don't forget that n'ko is a RTL language, then to write the number one hundred twenty three (123), we write "321" with n'ko digits.
In N'ko, we have our own digits. Here are the n'ko digits : ߀ ߁ ߂ ߃ ߄ ߅ ߆ ߇ ߈ ߉ Is it posible to replace the latin digits by the above n'ko digits in the n'ko version of libreoffice? I know that fix that might be complicated because of "%d", "%f".... PS : don't forget that n'ko is a RTL language, then to write the number one hundred twenty three (123), we write "321" with n'ko digits.
Please open a new RFE for that, it needs implementation not covered by this resolved "add a language" request.