Closed Bug 1360048 Opened 7 years ago Closed 6 years ago

[crh] Crimean Tatar: Firefox

Categories

(Mozilla Localizations :: Registration & Management, defect)

Product:
Mozilla Localizations
Component:
Registration & Management
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1446888

People

(Reporter: haqer, Unassigned)

References

Details

Attachments

(3 files)

firefox-58.0.1-crh-UA.xpi
380.05 KB, application/octet-stream
Details
compare_locales.txt
5.54 KB, text/plain
Details
dual.name.crh.png
3.29 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170413192749

Steps to reproduce:

For a number of years, there's been an unofficial lang pack addon (extension) for Crimean Tatar:
https://addons.mozilla.org/en-US/firefox/addon/qirimtatarca-til-destesi/

IMHO, it's time to get to a point where this locale is released officially by Mozilla. Subsequently, i intend on doing my best to contribute to ongoing updates for this locale (bug 350639).

My name: Reşat SABIQ
Email: haqer@gmx.fr
Site: http://tilde-birlik.sourceforge.net/
Locale can be: crh, crh-UA, crh-TR, etc. I'd lean towards just crh, unless a need emerges for more than one variant down the road...
Blocks: 350639
> Locale can be: crh, crh-UA, crh-TR, etc. I'd lean towards just crh, unless a
> need emerges for more than one variant down the road...
At the same time, i'd like the User-Agent to appear no different (to the max extent feasible) than Turkish Firefox for privacy reasons: i vaguely remember there are other l10ns doing something like that. Hopefully, this can be discussed down the road...
I would like to get actual, operational results here, as discussion on
dev-l10n-new-locales@lists.mozilla.org
hasn't produced absolutely nothing.

To reiterate, i've worked on Crimean Tatar localization for Firefox for over 9 years, & have kept up with releases since 10/14/2008! It's obviously time to get all this work into the Version Control System.

Over the years i've been bothered several times about privacy-related features of the current addon. I'd like to recap the interactions i've had related to that & my attempt this year to finally get all this work into VCS:
1. Jorge Villalobos was kind enough to allow these features even after several people raised questions about them over the years, but this year he has not stepped & left it up to others & the Crimean Tatar Firefox addon has been blocked since June (i submitted v54 update in June, & after sitting in queue for about 4 weeks it got blocked on July 21).
2. Andreas Wagner started questioning privacy-related aspects again in March, & in April blocked v52, vandalized the entire 9+ year history of the addon by disabling (or maybe even deleting[1]) not only v52 that he questioned, but all the versions & releases before it as well all the way since May 28 2008. He did this apparently by running an SQL statement. I would like to get his feedback on:
2.1. Why he disabled or deleted all the versions since 2008 through 2017, instead of just v52?
2.2. Is it common to do that (& apparently use SQL statements for that), or is it a sign of malicious intent? Has this been done against another addon for a trivial reasons like one involved here?
2.3. How & when is Andreas Wagner or AMO planning on reversing this vandalism, & showing any kind of respect to 9+ years of work?
The only version now listed is v53, which has changes Andreas Wagner wanted, which are actually completely unnecessary (& which i removed in v54, saying Firefox does that (restoring a couple of preferences) automatically without any additional code in the addon): so paradoxically, the only version listed on AMO, is actually the worst version which has unnecessary code which i was forced to put there by the reviewer just to get thru the review formality.
3. Philipp Kewisch has blocked v54, v55, & v56 of the addon from being listed on AMO, mentioning the same reasons of privacy-improving features brought up by Andreas Wagner.
4. Francesco Lodolo apparently was misled by Andreas Wagner's vandalism & interpreted Crimean Tatar as being a newly-starting l10n effort, pointing out that there's a preference for usage of tools like Pontoon or Pootle in the beginning (for tracking progress, etc.).
5. Jeff Beatty pointed out in April that some kind of automating tool would be helpful, & asked if i use another one.
6. Romi Hardiyanto pointed out that i had mentioned that i've been using Mozilla Translator, & ended his reply with:
"I think the general idea is to use MozillaTranslator using the current
mercurial layout. Then upload each files/the whole locale to
Pontoon/Pootle."
7. Axel Hecht has indicated that he thinks that the current privacy-related features of the Crimean Tatar add-on shouldn't be used. He has not said anything about the most import issue: getting 9+ years of work into the VCS.

I believe that Andreas Wagner's actions resemble what communists did when they burnt books in Arabic script (& other similar acts of vandalism): i feel like he spat in my face, & that such behavior is completely unacceptable. I also disagree strongly with Philipp Kewisch's actions: there's no need to block a fully functional addon with well documented special privacy-improving features in this fashion.

That being said, at this point i treat AMO as of secondary importance, because apparently i'm simply not gonna have the time to fight against all this B.S. happening in AMO (which to me seems like it might have been infiltrated by a few trolls), plus the XUL-related changes expected in Firefox. If after 9+ years of work, this is the result, what's the point of continuing down the same road? The vandalism is actually only carried out by 2 people, but the problem is everybody else, again similar to other times in recent & more distant history, keeps their silence, so the result is determined by the outrageous few (2). 

I'd like to focus on getting 9+ years of work into the VCS. In response to the afore-mentioned vandalism, i've had to spend additional time (again, despite the fact that i don't really have time for these kinds of extra tasks) to at least prove that i've indeed worked on this for 9+ years:
a. I've indicated percentage localized in the table (and as tooltips under the table) on 
http://tilde-birlik.sourceforge.net/
(what's not localized is in kindred Turkish locale (so it wouldn't really be too big an exaggeration to say localization is 100% complete))
b. I've made available all the versions' .xpi files i've submitted that have been released at:
http://tilde-birlik.sourceforge.net/dosyeler/l10n/mozilla/firefox/crh/xpi/
c. I've made available all the AMO reviews i readily found on my machine at (i could find more in backups, but i don't access to them or time for that right now):
http://tilde-birlik.sourceforge.net/dosyeler/l10n/mozilla/firefox/crh/amo-reviews/
d. I've made available all the AMO validation results i have at:
http://tilde-birlik.sourceforge.net/dosyeler/l10n/mozilla/firefox/crh/validation/
e. I've made available screenshots showing all the versions disabled by actions mentioned in item 2. above (basically, all 9+ years of work except v53 is currently disabled on AMO):
http://tilde-birlik.sourceforge.net/dosyeler/l10n/mozilla/firefox/crh/status-and-versions/

Need more proof of my commitment to this effort? 
* I actually finished v54 in June at the risk of missing a plane flight, which resulted in me running a bit late (risking wasting an $800+ plane ticket), which caused some trouble when driving... 
* I've continued l10n worked since June despite the fact that the localization has been blocked on AMO. 

As far as i can tell, i've made it clear that i'm committed to this effort. And i can tell you an additional reason why: i see this as not just an effort limited to Crimean Tatar localization. Crimean Tatar is a mix of Oghuz & Qipchaq features. Therefore, i see this is as something that could be useful beyond just Crimean Tatar locale in the long run (from Altay mountains all the way to the Eastern Mediterranean).

If you ask me, it's Mozilla who has something to prove. E.g.,
i. that if there are (people behaving like) trolls in AMO, etc., that other people can speak up & step up to achieve a reasonable outcome.
ii. that it's not behaving discriminatorily against me or Crimean Tatar language or Crimean Tatar people.
iii. that it acts in the spirit of open-source philosophy, & if not help, & at least that it doesn't try to put up artificial barriers and impede progress (especially for a locale that is having a hard time as it is).

A note on tools mentioned in April: had i spent time on Pootle, it would have been time wasted[2]. So you have to admit i made the right choice not to waste my time on a tool nobody really needs. To re-iterate from 04/29:
"for time management reasons i'd like to keep using Mozilla Translator (that i've been using all these years). If it's easy to just push the raw files or an archive into a tool like Pontoon i can spend some time on that too, if you are certain that you need it, but i don't have much extra time... If at some >point< Mozilla Translator becomes unsuitable, or there's another convincing, actual & proven need, then it would be justified to look into spending time on giving it up & changing the workflow."
For instance, i've heard that there might be a big change in localization files' format in the future (with change to something JSON-like). If Mozilla Translator becomes unsuitable at that point, THAT MIGHT be a good time to stop using it, & spend time on setting up something else (or if there's some other convincing benefit).

Finally, Mozilla has official releases in locales that don't have localizations for mozilla.org. I glanced at 
https://www.mozilla.org/en-US/firefox/all/
and
https://www.mozilla.org/en-US/
and found 2 examples in just 30 seconds (after which i stopped looking for more ex.s):
Maya Kaqchikel,
Oʻzbek tili

Lastly, the fact that Crimea has been annexed doesn't stop Crimean Tatar from being a language. You have all kinds of locales officially released & Crimean Tatar deserves to be as well. That said, once all the related l10n work is checked in, it will be up to you whether to release it or not, & in what fashion to release it. If you want it to be a vanilla lang pack, you will be able to easily release as a vanilla lang pack. If you would like to discuss other options with me, i'll gladly discuss them. But clearly, a locale with 84.5% localized ratio (and the rest in a kindred language), has a right at least to be checked in! To give you an example from a project that's actually acted rational about it: Gnome has released Crimean Tatar locale since 2009 (with no problems whatsoever; even though its localization never approached 84.5% (the highest was something like 38%, IIRC)).
https://l10n.gnome.org/teams/crh/
And, IIRC, Gnome has treated locales with 80+% localization ratios as officially supported! By memory, Pardus Linux (or its predecessor), also officially supports all locales 80+% localization ratios.

And if you don't know or understand something about Crimean Tatar locale, all you have to do is ask: i'll gladly try to answer any questions you have.

I hope that there are rational people in Mozilla reading this, who will speak up & stand up to achieve a reasonable solution (& leave all the non-sense that's been happening lately behind): if you are one of them, say something (under the circumstances, anything is better than nothing it seems).

-------
[1]  I do see all versions listed in developer account, but all but v53 are disabled. I tried downloading v51 and v50 from developer account & got:
"The add-on could not be downloaded because of a connection failure."
[2] "As of 23 August 2017, localization of Mozilla products is not available anymore through this instance of Pootle."
https://mozilla.locamotion.org/
(In reply to Reşat SABIQ (Reshat) from comment #2)

> A note on tools mentioned in April: had i spent time on Pootle, it would
> have been time wasted[2]. 

That's not correct. Content has been moved to Pontoon whenever needed, no content was lost.

> Finally, Mozilla has official releases in locales that don't have
> localizations for mozilla.org. I glanced at 
> https://www.mozilla.org/en-US/firefox/all/
> and
> https://www.mozilla.org/en-US/
> and found 2 examples in just 30 seconds (after which i stopped looking for
> more ex.s):
> Maya Kaqchikel,
> Oʻzbek tili

Not sure where you looked, but
https://www.mozilla.org/cak/
https://www.mozilla.org/uz/

The fact that one page is not translated doesn't mean that the website is not translated at all.

Before writing more messages, I strongly suggest to take a read at this link, and try to keep the discussion civil
https://www.mozilla.org/en-US/about/governance/policies/participation/

If you can't stop assuming those decisions were made with malicious intent or to push some political agenda, or name calling people, the discussion for me is over.

Regarding having an official Firefox build of Crimean Tatar:
* There seem to be serious privacy concerns related to the use of this locale, to the point that you're suggesting to not expose the language in Accept Languages headers. That means that users using this version will never get crh content when browsing.
* For that very reason, you don't plan to localize mozilla.org. That's the main promotion target for Firefox builds, without crh in Accept Languages you'll just end up reading Turkish content.
* You're one person. It might sound strange, but that's a serious concern for us. We ask all new locales to create a community around the localization effort, both for testing and ensure that the localization is maintained in the future. We have a couple of languages historically with one maintainer, but that's not something we want to encourage.

For all the reasons listed above, Crimean Tatar seems only fit to ship as a language pack on AMO. As said before, there are other languages in this situation.

Note that having content in VCS doesn't mean having language packs automatically built.

The language pack has been rejected for technical reasons, because it should ship as a language pack, not an add-on doing other things (including shipping binary components). It also shouldn't override general.useragent.locale to 'tr'.
(In reply to Francesco Lodolo [:flod] from comment #3)
> Not sure where you looked, but
...
> https://www.mozilla.org/uz/
This page is in English, and Language list on bottom of pages doesn't include this locale.
I spent 20 more seconds and found another example (also not in Language list on bottom of pages):
isiXhosa
(i don't have time to look for even more examples, but they are probably there).

> The fact that one page is not translated doesn't mean that the website is
> not translated at all.
It's not about 1 page, it's a general statement (about 2 locales found in less than a minute).

> Regarding having an official Firefox build of Crimean Tatar:
> * There seem to be serious privacy concerns related to the use of this
> locale, to the point that you're suggesting to not expose the language in
> Accept Languages headers. That means that users using this version will
> never get crh content when browsing.
> * For that very reason, you don't plan to localize mozilla.org. That's the
> main promotion target for Firefox builds, without crh in Accept Languages
> you'll just end up reading Turkish content.
There's not much content in crh anyway, but that's not a requirement to have an app or OS in crh. Mozilla.org could be looked into after reaching 100%, but again it's not been requirement for at least O'zbekcha and isiXhosa, & shouldn't be required for Crimean Tatar.

> For all the reasons listed above, Crimean Tatar seems only fit to ship as a
> language pack on AMO. As said before, there are other languages in this
> situation.
If that's what Mozilla in general decides to do, then Mozilla can i do it itself. I've not gotten anywhere on AMO in 9+ years.

> The language pack has been rejected for technical reasons, because it should
> ship as a language pack, not an add-on doing other things (including
> shipping binary components). 
My focus is VCS, but 0-length files are there for AMO not to increase maxVersion, which broke installations.
> It also shouldn't override
> general.useragent.locale to 'tr'.
You are contradicting yourself: you mentioned privacy concerns with crh locale, but you don't want to mitigate them. You cannot have have it both ways: only 1 of these sides can be picked.
And in either case, none of this is a blocker to check the locale in (just like other locales in similar circumstances). Let's focus on the most important thing first!

OK, Francesco Lodolo's position seems clear. Anybody out there who would actually think this thru a bit longer than in 36 minutes and would support a reasonable solution for checking into the VCS? It is important to speak out, because otherwise the result will remain unreasonable as it has been lately...
(In reply to Reşat SABIQ (Reshat) from comment #4)
> This page is in English, and Language list on bottom of pages doesn't
> include this locale.

Because the translation for *that* page is not available. Both xh and zu are behind with severely behind with mozilla.org translation, it doesn't meant that they are not there, or weren't fully localized at the time Firefox launched.

You can get the full list of locales enabled here, if you're curious
https://l10n.mozilla-community.org/webdashboard/

> My focus is VCS, but 0-length files are there for AMO not to increase
> maxVersion, which broke installations.

Was AMO increasing the maxVersion for an add-on shipping (and identified) as language pack? If that's the case, it's a bug on AMO's side. If it was already shipping as add-on, that's a different story.

> > It also shouldn't override
> > general.useragent.locale to 'tr'.
> You are contradicting yourself: you mentioned privacy concerns with crh
> locale, but you don't want to mitigate them. You cannot have have it both
> ways: only 1 of these sides can be picked.

That's the UI language, not Accept Languages, and it should be 'crh' if 'crh' is the locale code you're using.
http://kb.mozillazine.org/General.useragent.locale

As far as I know, and I might be wrong, it's not exposed to the outside (e.g. bug 448743). navigator.language returns 'it-IT' on my build, while general.useragent.locale is set to 'it'.

> Anybody out there who would actually think this thru a bit longer than in 36 minutes

I answered your first request 6 months ago in bug 350639. I had a bit more than 36 minutes to think about this topic.
(In reply to Francesco Lodolo [:flod] from comment #5)
> Both xh and zu are
> behind with severely behind with mozilla.org translation, it doesn't meant
> that they are not there, or weren't fully localized at the time Firefox
> launched.
Both locales are not used for the 2 most-important-looking pages, and are not listed under Languages (at least for those pages):
https://www.mozilla.org/en-US/firefox/new/
https://www.mozilla.org/en-US/firefox/all/
In fact, both of these locales are redirected to en-US pages. That says a lot about this not being that big of a deal for a released locale.[1]
On the other hand, if my time hadn't been continuously wasted here, i probably could've finished l10n of even mozilla.org by now...

> As far as I know, and I might be wrong, it's not exposed to the outside
> (e.g. bug 448743). navigator.language returns 'it-IT' on my build, while
> general.useragent.locale is set to 'it'.
I have reconfirmed that general.useragent.locale is included in Firefox 56 in URLs in points 3. & 4. (to clarify, point 4 is Help->Report deceptive site...) mentioned in July in the following email (i can include examples if needed):
http://tilde-birlik.sourceforge.net/dosyeler/l10n/mozilla/firefox/crh/amo-reviews/Re_%20Mozilla%20Add-ons_%20QIRIMTATARCA%20Til%20Destesi%20(Crimean%20Tatar%20Lang%20Pack)%2054.0%20didn%27t%20pass%20review.html
 
However, even if for one reason or another one believes that doesn't matter, i still believe it's time to check this work in at least for the following reasons:
I. At least the ease of installation, mentioned in point 1. in the email pointed to by the link above, & seeing pages in a kindred language for points 3. & 4. above is better for users, & it would already be some things valuable that a custom extension provides: if i'm going to release something as an addon, i'd at least want to have that.
II. If it's going to be a vanilla langpack anyway, & there's nothing special i can do, then Mozilla can do it at least just as well: there's no point to bother me about it.
III. Vandalism & waste of my time that's been happening on AMO (& again happening in discussions even like this, which still haven't led to anything good).
IV. The fact that i've worked on this for 9+ years.
V. The fact that the locale is now 84.5% localized (with the rest in a kindred language).
 
> I answered your first request 6 months ago in bug 350639. I had a bit more
> than 36 minutes to think about this topic.
Ultra-quick responses without thorough deliberation is just a sign. You haven't been objective in these 6 months. E.g., you have pointed out some policies to me personally twice. An objective person would have first asked a question like:
What policies are the acts of vandalism of 8-9+ years of my work based on?
Followed by questions i referred to earlier[2].
At this rate, even if i set a longevity record, i'm not holding my breath to get an objective feedback from you personally.

[1] And to me it looks a lot like documentation for Gnome, for instance: for most l10n teams documentation has secondary importance (e.g., Polish: 25% vs. 100% (https://l10n.gnome.org/teams/pl/)).
[2] (Quoting from comment #2):
2.1. Why he disabled or deleted all the versions since 2008 through 2017, instead of just v52?
2.2. Is it common to do that (& apparently use SQL statements for that), or is it a sign of malicious intent? Has this been done against another addon for a trivial reason like one involved here?
2.3. How & when is Andreas Wagner or AMO planning on reversing this vandalism, & showing any kind of respect to 9+ years of work?
A reminder for people being notified of this bug that Crimean Tatar, Crimean Tatars, & Crimean Tatar Firefox localization are still alive. The latest work is available from here:
http://tilde-birlik.sourceforge.net/dosyeler/l10n/mozilla/firefox/crh/xpi/firefox-58.0-crh-UA.xpi

Whatever foxes are running in the minds of people who are supposed to take care of this, i don't know: they haven't said much. There's been inexplicable procrastination & waste of time (including my time spent to write about this one more time).

Alas, Crimean Tatar localization has still not gotten anywhere here. I would like to kindly ask for official feedback from a Mozilla governance team (perhaps the Board of Directors)[1] regarding Mozilla's stance on the following questions:
1. Does Mozilla Foundation/Corporation recognize that Crimean Tatars are people, and there are Crimean Tatars who are alive? 
2. Does Mozilla Foundation/Corporation recognize that Crimean Tatars have the same rights as other people (e.g., for which Firefox localizations are available)? 
3. Does Mozilla Foundation/Corporation recognize that Crimean Tatar is a locale that can be used for localization of software (given other examples like Gnome, Wikipedia, etc.)?
4. Does Mozilla Foundation/Corporation acknowledge that the work on Crimean Tatar localization for Firefox has been going on consistently for the past 9+ years (taking into account vandalism that occurred on AMO in April of 2017 after which only 1 version (the worst of them) has been publicly reflected on AMO)?
5. Does Mozilla Foundation/Corporation acknowledge that Crimean Tatar localization for Firefox is now 84.8% complete (with the rest in a kindred language (Turkish))?
6. Does Mozilla Foundation/Corporation acknowledge that all this work has a right to at least be checked into Version Control System?

P.S.
[1] https://www.mozilla.org/en-US/about/leadership/
[2] I've seen Mozilla's slogan a few times that goes something like "browser built for people, not profit". It's time Mozilla actually starts acting like it. In this context, checking the l10n work in would be the first step in that direction.
Hi, at this point I'd like to clarify a few things.

Localization at Mozilla is coordinated by a group of employees called l10n-drivers. I'm part of that group and, among other things, I'm responsible for Firefox desktop localization.

Localization itself is managed by the Community. For other OS projects adding a new language might be just a matter of setting a flag in their tools or adding a folder to VCS, that's not the case for Mozilla. If you want to localize, you become a member of the Community, and you need to respect all its members.

I've already written it here and in the mailing list[1]: if you can't stop assuming that decisions were made with malicious intent or to push some political agenda, or name calling people, the discussion is over and I'm going to close this bug as WONTFIX.

There's no such thing as a universal right to commit content to VCS, or to be included in Firefox builds. We welcome any new contributions and locales – in fact, we added to our tools at least 4 languages in the past months, one just shipped in beta – as long as they maintain a cooperative attitude, and agree to follow a shared process to get to shipping official builds of Firefox. Bugzilla's contributor and etiquette guidelines

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

and Mozilla's community participation guidelines,

https://www.mozilla.org/en-US/about/governance/policies/participation/

represent our baseline standards for acceptable behavior. Failing to adhere to the Bugzilla etiquette guidelines will result in your Bugzilla account getting suspended.

If your locale is excluded, it will be for technical merits or your lack of cooperation, not for any other reasons.

Here's a possible path forward.

1) We recover content from your language pack and enable Crimean Tatar (crh) in Pontoon https://pontoon.mozilla.org/. Before an official Mercurial repository is created on hg.mozilla.org, you will have to keep up with localization for at least one full cycle via Pontoon (not Mercurial).

Mozilla Translator is not a supported tool, for several reasons, including the fact that it's not compatible with other tools (files are completely reformatted), and doesn't support FTL files (Fluent).

2) We add an official Mercurial repository and start building Nightly for this language. There's a lot of technical details to fix at this point, like creating a Bugzilla component, setting up searchplugins, build system, etc. That's also the reason we introduced the first step for new locales.

This require constant cooperation between the localization team and l10n-drivers.

At this point we also ask localization teams to start localizing mozilla.org. While it's not mandatory to complete the localization, at least some key pages should be completed to promote the localized build.

3) Locale stays on Nightly for at least 1 or 2 cycles after completing key parts. It can move to Beta and Release only if it a) keeps up with localization and b) builds a group of users on the Nightly channel.

4) Once in release, localization needs to be kept up to date. That's the most boring part of the work, but also the most important. That's also the main reason we try to avoid individual efforts, and prefer a group of volunteers working on the localization.

We realize that's a lot to ask for, and that not everybody will be comfortable with it, but these are the standards we have to meet to serve an audience of hundreds of millions of people aroung the world.

If you don't want to follow this path, you still have a chance to ship your localization of Firefox via AMO, by building and uploading a language pack. If the language pack is provided as an actual language pack, I don't expect AMO reviewers to have any issues with it.

[1] https://groups.google.com/d/msg/mozilla.dev.l10n.new-locales/pUklxNHk8wk/ijXO33iZAwAJ
(In reply to Francesco Lodolo [:flod] from comment #8)
> 1) We recover content from your language pack and enable Crimean Tatar (crh)
> in Pontoon https://pontoon.mozilla.org/. Before an official Mercurial
> repository is created on hg.mozilla.org, you will have to keep up with
> localization for at least one full cycle via Pontoon (not Mercurial).
I believe pontoon step could be skipped based on the facts like the following: 
* the work on crh localization has been going on consistently since at least May 28, 2008 (actually, it probably started many months before that first submission of 3.0.0.0.0 release to AMO, & thus may well have started over 10 years ago), 
& 
* app localization is at 84.8% (with the rest in kindred language (Turkish)). 
However, the most important thing is that I'd like to make some progress towards VCS, & if the only way this can happen reasonably quickly is by going through pontoon, then let's get that going.

> Mozilla Translator is not a supported tool, for several reasons, including
> the fact that it's not compatible with other tools (files are completely
> reformatted), and doesn't support FTL files (Fluent).
I'm used to MT, so at least until the first release through Mercurial, it seems to make sense to maintain the MT profile as well locally. At the same time, i definitely can't afford much of duplication of effort. From what i've seen after logging onto pontoon, i cannot upload files (which is possible for non-VCS-based-Gnome- & launchpad.net-based l10n work, for instance), but i can download them. So it seems the work-flow might go like this for now:
a. localize a file on pontoon;
b. download it;
c. import it into MT;
d. update MT metatada as needed (Translated/Proposed; Fuzzy/Not; etc.) (if the file is fully translated this should take no more than 15 seconds to select all rows, mark all as Translated & Not Fuzzy, & update);
e. repeat for another file (back to a.).

Please let me know when the ball is back in my court...
Also, as far as AMO: it only makes sense if there's something customized about the addon. And i still hope that AMO gets the history from May 28, 2008 until April 18, 2017 straightened out: otherwise, it's discouraging even for submittal(s) of something customized to AMO...

Please do let me know when the ball is back in my court...
(In reply to Reşat SABIQ (Reshat) from comment #9)
> I'm used to MT, so at least until the first release through Mercurial, it
> seems to make sense to maintain the MT profile as well locally. At the same
> time, i definitely can't afford much of duplication of effort. From what
> i've seen after logging onto pontoon, i cannot upload files (which is
> possible for non-VCS-based-Gnome- & launchpad.net-based l10n work, for
> instance), but i can download them. So it seems the work-flow might go like
> this for now:
> a. localize a file on pontoon;
> b. download it;
> c. import it into MT;
> d. update MT metatada as needed (Translated/Proposed; Fuzzy/Not; etc.) (if
> the file is fully translated this should take no more than 15 seconds to
> select all rows, mark all as Translated & Not Fuzzy, & update);
> e. repeat for another file (back to a.).

Given that you already translated most of the browser, I'd prefer you trying to use Pontoon directly, at least initially, instead of trying to keep Pontoon and MT in sync. Uploading and downloading is available per file, not per project, which makes things messy for a project the size of Firefox.

If that doesn't work, I'd like to understand what the issue is with Pontoon, and if it can be fixed (as long as it's not about mass upload/download of translations, because we don't want to turn Pontoon into a gateway to commit files).

For example, you'd have Turkish translations (and other locales) available directly in the UI when you translate.

(In reply to Reşat SABIQ (Reshat) from comment #10)
> Also, as far as AMO: it only makes sense if there's something customized
> about the addon.

If crh becomes an official language, it will be published as a standard language pack. As such, you can only customize the accept-languages value, other prefs can't be changed. Side note: general.useragent.locale has been dropped, and IIRC it was one of the things the old language pack was trying to change.

Let me know if I should set up crh on Pontoon at this point:
* You need to create an account and let me know the email you used, so that I can set you up as manager for that language.
* I will need to unpack your language pack, and restructure the files for the expected hg structure (which is different from a language pack). Can you attach your most recent work to this bug?

Is this data correct?
* Language name: Crimean Tatar
* Locale code: crh
* Plural forms: 2 (like Turkish, Azerbaijani)
(In reply to Francesco Lodolo [:flod] from comment #11)
> Uploading and downloading is available per file, not
> per project, which makes things messy for a project the size of Firefox.
So far i only saw an option to download a file, but not to upload one. Perhaps it's dependent on permissions. I'd certainly appreciate an option to upload a file as well.
If both are to be to kept in sync for a while, it could be possible to try to get a .xpi roughly equivalent to what's in pontoon, get it done (presently it's done about once every 6 weeks (per release)), & then to upload only the files that have changes in them (i.e., not all 300+ files).

> If that doesn't work, I'd like to understand what the issue is with Pontoon,
> and if it can be fixed (as long as it's not about mass upload/download of
> translations, because we don't want to turn Pontoon into a gateway to commit
> files).
I don't have much experience with pontoon, but there are a few things i like about MT:
1. Currently, it's easy to see/find/count what's been "inherited" from (Turkey) Turkish.
2. It's easier to see all changes for a release, & move from file to file.
3. There are some tools that help a bit here & there, like "Check for different endings"...
With time, it might not be possible to continue using it, so while it's still possible, it might be worth it.

> For example, you'd have Turkish translations (and other locales) available
> directly in the UI when you translate.
That would be helpful (sometimes i also glance at Azeri, Kazakh, Uzbek, French, etc. (the first 3 being listed on top of locales list is a good thing (Crimean Tatar being listed along them in general would also be a good thing, i believe))).

> Let me know if I should set up crh on Pontoon at this point:
Yes, please.
> * You need to create an account and let me know the email you used, so that
> I can set you up as manager for that language.
I signed up using the following email address: 
haqer@gmx.fr
> * Can you
> attach your most recent work to this bug?
Voilà (the attachment comes with this comment).

> Is this data correct?
> * Locale code: crh
1) Yes.
> * Language name: 
2.1) Crimean Tatar
This could be used, but slightly different naming might be worth considering. For instance:
2.2) Tatar, Crimean
The locale code is currently associated with a dual name:
Crimean Tatar; Crimean Turkish
Ubuntu has chosen to use a dual name, for instance:
https://translations.launchpad.net/ubuntu/bionic/+translations
Given that about 15% of localization is currently in Turkish, & some part of it (especially a part of devtools) might stay "inherited" like that for a while), i'd personally prefer a dual name, like that above, or as follows: 
2.3) Crimean Tatar (Crimean Turkish)
Other dual variations could also be considered:
2.4) Tatar, Crimean (Turkish, Crimean)
I'd prefer (in that order): 2.3, 2.4, 2.2, 2.1
That said, i definitely wouldn't spend time arguing much about it: it's not that big of a deal.
> * Plural forms: 2 (like Turkish, Azerbaijani)
3) Short answer: i'd prefer 2 plural forms
 (although 1 plural form could be considered sufficient, generally speaking).
Long answer: 
It is commonly accepted that Turkic languages in general have 1 plural form, & it is true. So when Turkish, Azeri, etc. in intl.properties have the following, it makes sense:
pluralRule=1
However, from experience, in certain cases phrases in the original language are structured such that having 2 plural forms allows a better matching (& perhaps better overall) localization. I mentioned a couple examples in 2009 on Ubuntu launchpad:
https://answers.launchpad.net/launchpad/+question/65693
A quick (whatever fit in grep -A 3) search of Firefox l10n, produces the following examples for which having 2 plural forms allows a better matching (& perhaps better overall) localization.[1]
At the same time, with 2 plural forms, in most cases, the 2 forms would be identical, so a bit of duplication of effort, & space would be the cost to pay for a achieving a slightly better localization in some cases.

A general note: some "fine-tuning" could be considered over the long term; it doesn't have to all be perfect & all be done at once.

P.S. 
[1] 
58.0/xpi/chrome/en-US/locale/en-US/mozapps/extensions/extensions.properties-showAllSearchResults=See one result;See all #1 results
With 1 plural form the translation would always be equivalent to plural in English: See all #1 results
58.0/xpi/browser/chrome/en-US/locale/browser/places/places.properties-cmd.deletePages.label=Delete Page;Delete Pages
With 1 plural form the translation would be equivalent to the following in English: Delete Page(s)
58.0/xpi/browser/chrome/en-US/locale/browser/places/places.properties-cmd.bookmarkPages.label=Bookmark Page;Bookmark Pages
With 1 plural form the translation would be equivalent to the following in English: Bookmark Page(s)
58.0/xpi/browser/chrome/en-US/locale/browser/browser.properties-addonDownloadingAndVerifying=Downloading and verifying add-on…;Downloading and verifying #1 add-ons…
With 1 plural form the translation would always be equivalent to plural in English: Downloading and verifying #1 add-ons…
58.0/xpi/browser/chrome/en-US/locale/browser/browser.properties-# #1 first add-on's name, #2 number of add-ons, #3 application name
58.0/xpi/browser/chrome/en-US/locale/browser/browser.properties-addonsInstalled=#1 has been installed successfully.;#2 add-ons have been installed successfully.
With 1 plural form the translation would always be equivalent to plural in English: #2 add-ons have been installed successfully.
(Note here, singular in English uses add-on name, which becomes impossible with only 1 plural form.)
xpi/browser/chrome/en-US/locale/browser/browser.properties-pendingCrashReports2.label = You have an unsent crash report;You have #1 unsent crash reports
With 1 plural form the translation would always be equivalent to plural in English: You have #1 unsent crash reports
xpi/browser/chrome/en-US/locale/en-US/devtools/client/inspector.properties-markupView.more.showAll2=Show one more node;Show all #1 nodes
With 1 plural form the translation would always be equivalent to plural in English: Show all #1 nodes
(In reply to Reşat SABIQ (Reshat) from comment #12)
> So far i only saw an option to download a file, but not to upload one.
> Perhaps it's dependent on permissions. I'd certainly appreciate an option to
> upload a file as well.

Yes, it depends on the permissions. 

As said, is available for single resource, which, in case of Firefox, means single file, not as a package of files.

> 1. Currently, it's easy to see/find/count what's been "inherited" from
> (Turkey) Turkish.
> 2. It's easier to see all changes for a release, & move from file to file.
> 3. There are some tools that help a bit here & there, like "Check for
> different endings"...

OK, these might be indeed hard to fix, especially #1. The existing use case is only "show me untranslated strings", since it's only possible to use English as source language. There are bugs on file to use an alternative source language, but I doubt they would help a lot here.

For #2, you can look at "All resources", or go file by file. Switching file is not as fast as MT (it's a couple of clicks away).

For #3, some QA views in Tranvision will help when crh is added to Nightly builds.

> That would be helpful (sometimes i also glance at Azeri, Kazakh, Uzbek,
> French, etc. (the first 3 being listed on top of locales list is a good
> thing (Crimean Tatar being listed along them in general would also be a good
> thing, i believe))).

In case you haven't seen it, you can customize the order of languages in your profile. If available, those translations will show on top the list, the rest alphabetically.

> > * Language name: 
> 2.1) Crimean Tatar
> This could be used, but slightly different naming might be worth
> considering. For instance:
> 2.2) Tatar, Crimean
> The locale code is currently associated with a dual name:
> Crimean Tatar; Crimean Turkish
> Ubuntu has chosen to use a dual name, for instance:
> https://translations.launchpad.net/ubuntu/bionic/+translations
> Given that about 15% of localization is currently in Turkish, & some part of
> it (especially a part of devtools) might stay "inherited" like that for a
> while), i'd personally prefer a dual name, like that above, or as follows: 
> 2.3) Crimean Tatar (Crimean Turkish)
> Other dual variations could also be considered:
> 2.4) Tatar, Crimean (Turkish, Crimean)
> I'd prefer (in that order): 2.3, 2.4, 2.2, 2.1

I'm not sure about using a semicolon (2.2), the length might be a problem. I think we can start with 2.3, and change later in case.

DevTools: the long term goal is to split them out of main Firefox, and have fallback. You wouldn't have to copy Turkish translations there, just stop translating DevTools all together for crh. In that case, it sound like "Crimean Tatar" would be the best choice?

> That said, i definitely wouldn't spend time arguing much about it: it's not
> that big of a deal.
> > * Plural forms: 2 (like Turkish, Azerbaijani)
> 3) Short answer: i'd prefer 2 plural forms
>  (although 1 plural form could be considered sufficient, generally speaking).

OK.

> Long answer: 
> It is commonly accepted that Turkic languages in general have 1 plural form,
> & it is true. So when Turkish, Azeri, etc. in intl.properties have the
> following, it makes sense:
> pluralRule=1

To clarify (because it's really confusing…): 1 is the number of the rule, not the number of plural forms.

#1 = 2 forms, exactly like English

Both az and tr where using rule #0, which means "1 form". While it covers most cases, it doesn't cover them all. The downside is that you need to copy the same text over, even if the translation is correct.

I'll start looking into the language pack, and update the bug when Pontoon is available.
Attached file compare_locales.txt — 
Looks like CLDR is using "Crimean Turkish"
https://github.com/unicode-cldr/cldr-localenames-full/blob/master/main/en/languages.json#L120

I've reorganized the content in the language pack and made a few changes.

1) Set pluralRule to 1 (like tr, az).

2) Set general.useragent.locale to crh. As said, this is a key that has already been removed in 59, so the impact is basically non existent for Nightly, but it's still correct to match the locale code in the meantime. I left the acceptLanguages key unchanged, leaving Turkish as first.

3) Restored default region.properties, since it's a new locale, and removed the /searchplugins folder (that shouldn't be in the language pack at all).

4) Removed some obsolete files.

branding/browserconfig.properties
browser/chrome/browser/appstrings.properties
browser/chrome/browser/bookmarks.html
browser/chrome/browser/downloads/settingsChange.dtd
browser/chrome/browser/netError.dtd

Note that some more obsolete files are present in the XPI, e.g. Loop’s translation.

Attached is the result of compare-locales run between crh and https://hg.mozilla.org/l10n/gecko-strings

It's in pretty good shape, but it would be good to fix the WARNINGs where the entity replacement is not needed. There will be more warnings once we set up checks for plurals. Some files are missing because they're not part of a language pack (crash reporter, installer).

Project is available on Pontoon, and permissions are set up. As said, I'd really like you to try using Pontoon directly and see how that works for you, more than trying to keep MT and Pontoon in sync.
https://pontoon.mozilla.org/crh/

I've also added "Activity Stream" (the New Tab in Firefox). There's also Firefox Screenshots shipping as part of Firefox, but I'd wait for that, unless you already want to look into it too•
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Francesco Lodolo [:flod] from comment #13)
> DevTools: the long term goal is to split them out of main Firefox, and have
> fallback. You wouldn't have to copy Turkish translations there, just stop
> translating DevTools all together for crh. In that case, it sound like
> "Crimean Tatar" would be the best choice?
The inheriting is not limited to devtools: e.g., pippki & pipnss is also partially inherited. I'd leave the name as is for now...

> #1 = 2 forms, exactly like English
Good point: i forgot about that.
> Both az and tr where using rule #0, which means "1 form". While it covers
> most cases, it doesn't cover them all. The downside is that you need to copy
> the same text over, even if the translation is correct.
It seems a lot of Turkic languages have moved to 2 plural forms in the last few years: because some things are better localized with 2 plural forms in comparison to 1. For Ubuntu uz & crh probably need this change as well going forward:
https://translations.launchpad.net/+languages/uz

(In reply to Francesco Lodolo [:flod] from comment #14)
> 1) Set pluralRule to 1 (like tr, az).
OK. 
> 2) Set general.useragent.locale to crh. As said, this is a key that has
> already been removed in 59, so the impact is basically non existent for
> Nightly, but it's still correct to match the locale code in the meantime. I
> left the acceptLanguages key unchanged, leaving Turkish as first.
Some Help menu items have been dependent on general.useragent.locale. I guess they no longer are, but it's worth verifying that.
> 3) Restored default region.properties, since it's a new locale, and removed
> the /searchplugins folder (that shouldn't be in the language pack at all).
Actually, en-US.xpi & tr.xpi both have it & contents differ: maybe this is generated out of Mercurial though...
> 4) Removed some obsolete files.
> 
> branding/browserconfig.properties
> browser/chrome/browser/appstrings.properties
> browser/chrome/browser/bookmarks.html
> browser/chrome/browser/downloads/settingsChange.dtd
> browser/chrome/browser/netError.dtd
This is probably post-58 changes.
> Note that some more obsolete files are present in the XPI, e.g. Loop’s
> translation.
This is an empty folder that got left by oversight from the past...

> Attached is the result of compare-locales run between crh and
> https://hg.mozilla.org/l10n/gecko-strings
> 
> It's in pretty good shape, but it would be good to fix the WARNINGs where
> the entity replacement is not needed. There will be more warnings once we
> set up checks for plurals. Some files are missing because they're not part
> of a language pack (crash reporter, installer).
OK, that will be first on the TODO list.

> Project is available on Pontoon, and permissions are set up.
Looks good so far.

> I've also added "Activity Stream" (the New Tab in Firefox). There's also
> Firefox Screenshots shipping as part of Firefox, but I'd wait for that,
> unless you already want to look into it too•
I think adding Firefox Screenshots now would be OK.

I'd appreciate your feedback on the following. Roughly as 15:50 UTC on 2018-01-30, is pontoon roughly (or nearly exactly) the same as the following en-US.xpi:
http://ftp.mozilla.org/pub/firefox/nightly/2018/01/2018-01-30-10-29-29-mozilla-central/firefox-60.0a1.en-US.langpack.xpi
If not, which nightly build is it roughly equivalent of?

P.S. I might take a week or two off this work, but will keep it fairly high on my TODO list.
> I'd appreciate your feedback on the following. Roughly as 15:50 UTC on
> 2018-01-30, is pontoon roughly (or nearly exactly) the same as the following
> en-US.xpi:
> http://ftp.mozilla.org/pub/firefox/nightly/2018/01/2018-01-30-10-29-29-
> mozilla-central/firefox-60.0a1.en-US.langpack.xpi
> If not, which nightly build is it roughly equivalent of?

Yes, it should be the same content as Pontoon at the moment.

In terms of hg structure, this
https://hg.mozilla.org/l10n/gecko-strings/file/ab5a9a5effb8

While Turkish content is here
https://hg.mozilla.org/l10n-central/tr/
I changed the language name to "Crimean Tatar":
https://pontoon.mozilla.org/crh/

We only put country names in brackets, so let's keep that consistent:
https://pontoon.mozilla.org/teams/
Attached image dual.name.crh.png — 
(In reply to Matjaz Horvat [:mathjazz] from comment #17)
> I changed the language name to "Crimean Tatar":
> https://pontoon.mozilla.org/crh/
> 
> We only put country names in brackets, so let's keep that consistent:
> https://pontoon.mozilla.org/teams/
I'd prefer a dual name. E.g., following conventions used for Gaelic and Sorbian: 
Crimean Tatar, Crimean Turkish
If the style 
.locale.select .menu{display:none;position:absolute;width:252px}
(from https://pontoon.mozilla.org/static/css/translate.min.17ed57ed6abb.css)
is updated to have
width:263px
then the UI would like in the attached screenshot (namely, fitting quite well).
But if that's difficult for some reason we can leave it as it is now.
(In reply to Francesco Lodolo [:flod] from comment #13)
> It's in pretty good shape, but it would be good to fix the WARNINGs where
> the entity replacement is not needed. 
I've just taken care of 5 of these WARNINGS (the 6th (healthReport2.label) is no longer around, so it's "auto-taken-care-of").

(In reply to Francesco Lodolo [:flod] from comment #8)
> 1) We recover content from your language pack and enable Crimean Tatar (crh)
> in Pontoon https://pontoon.mozilla.org/. Before an official Mercurial
> repository is created on hg.mozilla.org, you will have to keep up with
> localization for at least one full cycle via Pontoon (not Mercurial).
...
> 2) We add an official Mercurial repository and start building Nightly for
> this language.
Do i understand correctly that we've gone thru 1 cycle on Pontoon, and crh can move on to Nightly stage (it would probably be more time-efficient)?
(In reply to Reşat SABIQ (Reshat) from comment #18)
> I'd prefer a dual name. E.g., following conventions used for Gaelic and
> Sorbian: 
> Crimean Tatar, Crimean Turkish

For both those languages the name is only one ("Scottish Gaelic", "Upper Sorbian") just written with a comma. Not even completely sure why that's the case for gd, while it's quite common for languages including Northern, Lower, etc.

For Crimean, I guess it would be equivalent to "Tatar, Crimean"?

> (In reply to Francesco Lodolo [:flod] from comment #8)
> > 1) We recover content from your language pack and enable Crimean Tatar (crh)
> > in Pontoon https://pontoon.mozilla.org/. Before an official Mercurial
> > repository is created on hg.mozilla.org, you will have to keep up with
> > localization for at least one full cycle via Pontoon (not Mercurial).

I see that you started updating the localization via Pontoon in the past days. That's probably not a full cycle, but given the percentage of translation, I'll start the process to create an official repository this week, and have Nightly builds. 

Note that it will take a bit of time to get there.

One final note: having official hg repository doesn't mean having hg access. Initially localization will still happen via Pontoon, if you still want to use Mercurial we'll need to go through some test bugs to review patches before getting write access.

Also note that Mozilla Translator, at this point, is officially not suitable for localizing Firefox (there's no plan to support Fluent syntax at the time). So, localizing via Mercurial would mean using a text editor.
(In reply to Francesco Lodolo [:flod] from comment #20)
> For Crimean, I guess it would be equivalent to "Tatar, Crimean"?
Ideological games since about a century ago have generated a situation in which this kind of spelling would seem to bother a fairly big proportion of people (specifically, in Crimea). For that reason, i'd not vote for it. If dual name is not suitable, we can leave it as it is now: dual name is a kind of a "nice-to-have" IMHO. If not now, perhaps it can be kept in mind for the future.

> Initially localization will still happen via Pontoon, if you still want to
> use Mercurial we'll need to go through some test bugs to review patches
> before getting write access.
Yes, i'd like the process to be started, & will try provide the patches to review, etc.

> Also note that Mozilla Translator, at this point, is officially not suitable
> for localizing Firefox (there's no plan to support Fluent syntax at the
> time). So, localizing via Mercurial would mean using a text editor.
MT is still kind of useful from my PoV, because it allows tracking entries inherited from Turkish (even though i don't have time to translate specifically those entries, it still seems to provide a bit of value (there are also features like auto-translation with Approximated, Copied, Proposed, etc., statuses which Pontoon may or may not be providing)). But i have noticed Fluent files in v59, & yes i had to handle them without MT.

(In reply to Francesco Lodolo [:flod] from comment #14)
> There's also
> Firefox Screenshots shipping as part of Firefox, but I'd wait for that,
> unless you already want to look into it too•
Feel free to add this as well, when you have some time for it.
(In reply to Reşat SABIQ (Reshat) from comment #21)
> (In reply to Francesco Lodolo [:flod] from comment #20)
> > For Crimean, I guess it would be equivalent to "Tatar, Crimean"?
> Ideological games since about a century ago have generated a situation in
> which this kind of spelling would seem to bother a fairly big proportion of
> people (specifically, in Crimea). For that reason, i'd not vote for it. If
> dual name is not suitable, we can leave it as it is now: dual name is a kind
> of a "nice-to-have" IMHO. If not now, perhaps it can be kept in mind for the
> future.

OK. Let's keep "Crimean Tatar" then.

> > There's also
> > Firefox Screenshots shipping as part of Firefox, but I'd wait for that,
> > unless you already want to look into it too•
> Feel free to add this as well, when you have some time for it.

Added.

Asking a few questions that I will need to start filing the bugs. We need to create a Bugzilla component for crh.

Locale code: crh
Language name: Crimean Tatar (we don't use commas for any language name here)
Description: Crimean Tatar Localization
Localized description: ???

We need the translation in Crimean Tatar of this description.

If you want, we can use "Crimean Tatar (Crimean Turkish) Localization" for the description. In case let me know, so we can use the same for both English and localized version.

Once I'll start filing bugs, I'll cc you to them, since I will need more information (e.g. for searchplugins).
(In reply to Francesco Lodolo [:flod] from comment #22)

I can suggest another option for Pontoon (without commas or parentheses):
Crimean Turkish-Tatar
This would be consistent with a native term used in some sources at least since the publication of the following book (whose name here is transliterated to the current alphabet): 
Türk-tatar tili: 1-nci basamaq mekteplerniñ 4-nci ve 5-nci sınıfları içün oquv kitabı.
Aqmescit
1923
In translation:
Turkish-Tatar language: reading book for 4th and 5th classes of 1st level schools.

> Locale code: crh
> Language name: Crimean Tatar (we don't use commas for any language name here)
> Description: Crimean Tatar Localization
> Localized description: ???
The following could be used for description:
I.
English:
Crimean Tatar (Crimean Turkish) Localization
Translation:
QIRIMTATAR Tili (Qırım Türkçesi) Mahalliyleştirmesi
II. Possible shorter alternative in case both English verbiage and its translation will (frequently) be provided next to each other:
Crimean Turkish Localization
QIRIMTATAR Tili Mahalliyleştirmesi

P.S. The word QIRIMTATAR is usually written as Qırımtatar (in beginning of sentence, or in titles, etc.), but i prefer upper-casing it. If you'd like to use the other spelling, i guess that's fine.
(In reply to Reşat SABIQ (Reshat) from comment #23)
> I can suggest another option for Pontoon (without commas or parentheses):
> Crimean Turkish-Tatar
> This would be consistent with a native term used in some sources at least
> since the publication of the following book (whose name here is
> transliterated to the current alphabet): 
> Türk-tatar tili: 1-nci basamaq mekteplerniñ 4-nci ve 5-nci sınıfları içün
> oquv kitabı.
> Aqmescit
> 1923
> In translation:
> Turkish-Tatar language: reading book for 4th and 5th classes of 1st level
> schools.

My concern would be using different names in different places for the same locale code (crh).

We should identify one, and stick to it everywhere (Pontoon, Bugzilla), so it's worth trying to figure it out now.

I see the double name here (Crimean Tatar Crimean Turkish)
http://www-01.sil.org/iso639-3/documentation.asp?id=crh

But I also see it listed only as "Crimean Tatar" here, which seems to indicate "Crimean Tatar" is the preferred form between the two.
http://www-01.sil.org/iso639-3/codes.asp?order=639_3&letter=c

Interestingly, CLDR seems to go in a completely different way: Crimean Turkish
https://github.com/unicode-cldr/cldr-localenames-modern/blob/master/main/en/languages.json#L120

I can't find any reference to "Crimean Turkish-Tatar", only pages talking about "Turkish and Tatar", but I have to trust your expertize on this. 

Do we agree on using "Crimean Turkish-Tatar" then?

> English:
> Crimean Tatar (Crimean Turkish) Localization
> Translation:
> QIRIMTATAR Tili (Qırım Türkçesi) Mahalliyleştirmesi

Length shouldn't be an issue for the description. But should we go with "Crimean Turkish-Tatar localization" for consistency then?
The reality is such that different names are in use. It seems the following generalizations could be made:
* In Crimea, it's usually Crimean Tatar (Qırımtatarca, Qırımtatar tili), but other variations are also used, including Qırımca (Crimean).
* In Dobruca, it's usually just Tatar (Tatarca or Tatar Tĭlĭ); this kind of usage can also be encountered in Turkey.
* Crimean Turkish or Kırım Türkçesi is frequently encountered in English and Turkish.
All these terms are used to refer to the same language.

Another consideration is that a part of localization is likely to continue to be inherited from Turkish due to the scale of the effort required compared to the available resources to do it. Which is a reason why a dual name seems logical to me personally...
(In reply to Reşat SABIQ (Reshat) from comment #25)
> Another consideration is that a part of localization is likely to continue
> to be inherited from Turkish due to the scale of the effort required
> compared to the available resources to do it.

Let's completely ignore this part, it doesn't matter if some strings are copied from Turkish. Hopefully, we'll reach a point where this is not even needed, and you can fall back to Turkish directly for missing strings.

Can we settle on a name among these, and adapt the bug component description accordingly?
* Crimean Tatar
* Crimean Turkish-Tatar
* Crimean Turkish

Bug component description: XXX Localization
Localized bug component description: ???

Where XXX is the name picked above.

I'd like to avoid spending too much time on this, and try to focus on more important things (e.g. setting up repos and nightly).

P.S. we have a Tatar (tt) enabled in Pontoon
With the reservation that this does not mean that there is no variation in the real-world usage, we can start off as follows:

Locale code: crh
Language name: Crimean Tatar
Description: Crimean Tatar Localization
Localized description: QIRIMTATARCA Mahalliyleştirme

P.S. The all-caps spelling of the 1st word in description is my (personal) preference. If the conventions in use don't allow it, then it would be:
Qırımtatarca Mahalliyleştirme
P.P.S. Dual-name across locales as follows would also be acceptable, IMHO:
Language name: Crimean Turkish
Description: Crimean Turkish Localization
Localized description: QIRIMTATARCA Mahalliyleştirme
(or without all-caps: Qırımtatarca Mahalliyleştirme)
This would mean a single name in English and a single localized name, but duality reflected between/across them.
I agree that setting up repos & nightly is more important, so feel free to make a call on this approach vs. the one listed earlier in this comment.

Thank you for your time.
Thanks, I started filing the bugs. Note that I will file the bugs also for mozilla.org, since that's part of the process, but the priority remains Firefox itself for now.

I'm going to duplicate this against bug 1360048, since that's the tracker bug for releasing Firefox.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: