Comment 48 for bug 323041

It appears you have agreed with all the points i have mentioned, but i'd like to shortly follow up on your comment for point 2.:

> > 2. AFAIK, and this is probably a well known fact but i'm going to be
> > conservative and not state that assertively, the majority or all keyboard GUIs
> > do not reflect variant keyboard layouts not defined under the particular
> > country.
> The gnome GUI is using the meta-information, available in base.xml. If some GUI
> tools are ignoring that - let their users file bugs. It is irrelevant here.

Based on my testing, only variant keyboard layouts defined under the particular country are reflected by the gnome GUI as well. But as i mentioned earlier in item 3., even if one or some GUI(s) handled it, ignoring (most) other GUIs would be equivalent to 2nd class treatment, in comparison to the treatment given to other locales.

The rest of your last comment is in line with what i've been doing all along. So i went ahead and committed Crimean Tatar (Crimean Turkish) layouts one more time.

> Anything I missed?

It makes more sense to base Crimean Tatar (Crimean Turkish) keyboard layouts in tr file, which is how i've checked it in.
a. Using symbols/ua as the base file would lead to circular "dependency" (ua->tr, tr->ua), which is commonly accepted to be a bad practice[1] even if it doesn't break anything, especially if it can be easily avoided.
b. Even if there wasn't a circular dependency, it also makes sense to base a keyboard layout based on Turkish one in tr file just out of pure common sense, and because it makes it easier to follow and maintain.
c. What i've checked in is also consistent with how layouts for other locales are provided in such circumstances (i.e., doing it otherwise would again mean inconsistent treatment for crh locale).

Finally, in case you consider an imposition one more time, i feel the need to re-iterate my position on the conflict of interest:
If a subject of a country that has for centuries practised ethnic cleansing, expulsion, and genocide of Crimean Tatars, and suppression of their rights, reverts Crimean Tatar keyboard layouts, or otherwise dictates the specifics of how they have to be defined, that constitutes "political B.S." that cannot be tolerated. You have laid out some general rules for this project already, and they already restricted the options for defining Crimean Tatar layouts, which in itself is something that you may not have the legitimate authority to do. Even though i still think you don't have the legitimate authority to dictate whether a language can be defined at a layout level rather than a variant level, because there are clearly examples of that that have similar characteristics, I have followed these general rules from day one. These general rules is as far as your word goes, and even those general rules are not beyond challenging, even though i've not challenged them.

I hope you will not revert this last commit, and will stop dictating the specifics of layouts of a locale with which you clearly have a conflict of interest. Barring any further interference, i hope this initial release of Crimean Tatar (Crimean Turkish) keyboard layouts will finally be made, and this bug will finally be closed. As time goeson , tweaks can be made to these layouts, if there is a legitimate basis, just as tweaks are regularly made to other layouts.

--------------------------------------
Footnote:
[1] As an illustrative example, in the world of enterprise java, 2 EJBs A and B each trying to inject a dependency on the other, would lead to a runtime error at deployment time (i've seen that in action on JBoss app server).