Patches for Crimean Tatar (Crimean Turkish) keyboard layouts

Checked in.

Resat, you've added crh variants to 6(!) countries. Why? Could you please explain? I guess it is only needed in symbols/ua - I'd appreciate if you remove it from other countries.

Also, the description in base.xml.in should match the group name in symbols file.

It is a bit of a mess now, so please do it ASAP (otherwise I'd have to revert your change). Thanks.

Also, next time before committing anything (especially so large) to xk-c, contact xkb maillist or me personally.

Actually, you also committed .po file which should only be added from Translation Project.

So, let's do it the proper way. I am reverting your patch, and could you please attach your changes here so we could discuss them?

Why am i not surprised. A question posted, and revert is made 6 minutes later. You had no grounds to revert everything!

I have a sneaky suspicion that you are just trying to make it difficult, after all the time i've spent to finally get this checked in.

Anyway, i'm not sure if it will help, but here are the answers to your questions.
1)
> Resat, you've added crh variants to 6(!) countries. Why? Could you please explain? I guess it is only needed in symbols/ua - I'd appreciate if you remove it from other countries.
Answer:
Because due to expulsions from native lands, performed by the way by the country that you represent, the nation is dispersed with proportionally large communities (and even w/ some alphabet variations) in at least 4 countries: tr, ua, uz, ro. These 4 are not up to discussion, based on even the most pessimistic estimates. Poland and Bulgaria might be discussed, but i decided to check them under those countries too, because communities are present there as well: and there's even a film about the community in Poland. If you were going to revert anything, you could somewhat plausibly revert the layouts under those 2 countries, at least for the time being.

2)
> Also, the description in base.xml.in should match the group name in symbols file.
Answer:
That could've been updated. That is no reason to revert anything.

3)
> Actually, you also committed .po file which should only be added from Translation Project.
Answer:
That is not a reason to revert, and even if it was, it would only warrant reverting the 1 .po file. TP arrangement can be made in time for the next release, but i do not see why a file that has already been provided couldn't stay checked in.

------
To wrap up, you could've possibly reverted, after discussion, pl, bg, and .po file, but not everything! I specifically notified you of this check-in, in case something was really flawed. I think reverting like that w/o any grounds for it, and w/o any discussion is an abuse. This is an open source project for the entire open source community, and not your personal one.

I also logged bug 19978:
http://bugs.freedesktop.org/show_bug.cgi?id=19978

If keyboards were grouped by languages, no time would be being wasted on this discussion right now.

I've reverted the patch because more than one rule was violated. When I made the very first comment, I was not going to revert - but then I found there are more issues, that's what triggered my decision.

Regarding "grouping by language". Did you try the "countryList" feature in base.xml.in? It works for ata and lat layouts.

(In reply to comment #7)
> I've reverted the patch because more than one rule was violated. When I made
> the very first comment, I was not going to revert - but then I found there are
> more issues, that's what triggered my decision.
The only rule my commit didn't strictly adhere to is rule 5:
http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules
The wording in base.xml.in was slightly different, although that doesn't appear to be a precedent, as even now such claims could be made against some files in the repo. Is that grounds enough to revert something? Could that not have been updated in a civilized manner?
No, what you are giving now is an excuse. When after a year or so of no action, you were asked to approve my account by freedesktop.org, you ignored it for another 4 months, and then again gave some kind of excuse. Now you gave another excuse for scandalizing matter. I see a pattern of unwelcoming hostile attitude here.

> Regarding "grouping by language". Did you try the "countryList" feature in
> base.xml.in? It works for ata and lat layouts.
I'm not following how this relates to Crimean Tatar keyboard layouts. Does this feature facilitate grouping keyboard layouts by language so that they are easier for the user to find (and to alleviate your concern about multiple files, which by the way is the approach used for several other languages)? If not, i don't think it is relevant. Are you not objecting to a single crh file containing the keyboard layouts for Crimean Tatar (as is the case for Arabic, and latam)? If you are, what can countryList contribute then?

I don't see how countryList feature is relevant, but even if it somehow is, again it doesn't excuse your hostile revert. I followed the rules, w/ 1 overlooked aspect that could have been easily updated. And that 1 rule says nothing about not giving any time for the contributor to address it or discuss it.

Moreover, as far as i gathered in 10 minutes of looking through it, rule 5 isn't strictly followed by " Use guillemets for quotes" description under Bosnia (there is an extra space), and 'Dvorak, Polish quotes on key "1/!"' under Poland (the quotes constitute a difference). And correct me if i'm wrong (i don't really have time to analyze this much), but file symbols/nec_vndr/jp is breaking rule 1 from
http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules
by not defining a group. Why don't you go ahead and revert such files? Does that sound outlandish? Your behavior is just as outlandish, to say the least.

It is very unfortunate that after expelling the people from their lands, the keyboard layouts have now been expelled from the files of the countries where the people ended up settling down, by somebody who is apparently a subject of the country that expelled the people. The notion of conflict of interest doesn't even begin to describe this. I think this behavior may not be your fault individually, and if your grew up and lived in a different country, ceteris paribus, you probably would not be behaving like this, but that doesn't change the reality.

To wrap up, based on your ignoring and unwelcoming at first, and now hostile behavior, and the fact that you...

Political issues have nothing to here (I am half-Tatar, fyi). I just do not want keep the codebase maintainable.

> Are you not objecting to a single crh
Yes.

> If you are, what can countryList contribute then?
If you create ua(crt), you still have ability to add countryList to that variant (in base.xml). Then it's up to GUI (if it does not handle that scenario correctly, it should be fixed).

About the countries. Looking at http://en.wikipedia.org/wiki/Crimean_Tatars, I see it would be perfectly sane to add that variant just to the Ukraine, since Uzbekistan, Turkey and Romania have much smaller populations (and using countryList should make them happy enough).

Since you're saying you're not interested in further discussion, I am closing this one. Feel free to reopen if you're ready to discuss.

First of all, i'd like to note that you have not followed up on any procedural violations that you have made in reverting. Maybe it's a good thing, because frankly i'm sure you can make up more excuses, but i don't have time to argue about it.
It is becoming clear from every single post you make and every single action you take in this particular matter, that you are acting like a saboteur.
I'll go back to clarify 1 more detail first.
Earlier, i wrote:
> When after a year or so of no action, you were asked to approve my
> account by freedesktop.org, you ignored it for another 4 months, and then
> again gave some kind of excuse.
What i should have mentioned as well, is that even after you were asked to approve my account, and 4 additional months passed, you didn't do or say anything about that account anyway, until freedesktop.org tried to close that account bug as too old, and i re-opened it. That was my first encounter with you. It was followed by your sabotage of Crimean Tatar (Crimean Turkish) layouts 2 months ago. And now you are continuing down the same path.

Now on your last consistently-abusive action and post:

(In reply to comment #9)
> Political issues have nothing to here (I am half-Tatar, fyi). I just do not
> want keep the codebase maintainable.
I think i'd seen a post from you somewhere way back where i saw you mentioning that, and perhaps one of your parents really is a Volga Tatar, but of course it makes no difference whatsoever with regards to the matter at hand. You may be half gold, and half platinum, or 100% gold or platinum, and it still won't change the fact that you apparently are a subject of a country that has
for centuries practiced ethnic cleansing, deportation, and genocide of Crimean
Tatars, and suppression of their rights (whose present treatment of minorities and dissidents is well known), and it also won't change your track record with regards to this issue.
>
> > Are you not objecting to a single crh
> Yes.
Why am i not surpised.
>
> > If you are, what can countryList contribute then?
> If you create ua(crt), you still have ability to add countryList to that
> variant (in base.xml). Then it's up to GUI (if it does not handle that scenario
> correctly, it should be fixed).

You must have brought this up only to waste my time and muddy up the water.
1. This is not how it's done for other locales. You are effectively treating Crimean Tatar (Crimean Turkish) locale as 2nd class.
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. Again, this shows that you are effectively treating Crimean Tatar (Crimean Turkish) locale as 2nd class.
3. Even if some GUIs now do something w/ countryList for variant keyboards, leaving some or most other GUIs out, would again be equivalent to treating Crimean Tatar (Crimean Turkish) locale as 2nd class.

> About the countries. Looking at http://en.wikipedia.org/wiki/Crimean_Tatars, I
> see it would be perfectly sane to add that variant just to the Ukraine, since
> Uzbekistan, Turkey and Romania have mu...

Sorry for not another delay, at least now I added xkb maillist to CC list here, so will be able to react faster. But I kindly ask you (again) to refrain from using political BS here. This is pure technical/processual matter.

> 1. This is not how it's done for other locales.
That's true. I am trying to create a solution which would allow to minimize the duplication of the code (well, may be I am slightly paranoidal at that point).

> 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.

> 4. Romania requires customizations and thus is not up to discussion.
Ok, no arguing here.
> To wrap up, none of the 4 countries can be dismissed.
Looked at the links, thought a bit. Generally, agree.

So, what I would be happy with is:
1. Add crt variant to symbols/ua
2. Add crt variant to uz and tr. For example:

partial alphanumeric_keys
xkb_symbols "crh" {
    include "ua(crh)"
    name[Group1]= "Uzbekistan - Crimean Tatarian";
};

3. Add ro(crt) by inclusion of the original variant + whatever tweaks you think are necessary.
4. Modify base.xml.in accordingly: add 4 variants crh to ua,uz,ro,tr, use languageList to indicate crh as a language.

Anything I missed?

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 mad...

> 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
Actually, there are very few GUI tools. The most used ones are in GNOME and KDE. Both are based on libxklavier, which I have full control over. So if there is a bug - I can fix it for both GNOME and KDE.

> tr file, which is how i've checked it in.
> a. Using symbols/ua as the base file would lead to circular "dependency"
Ok, that's fair.

(Sorry, I did not read the political part of your comment, the commit is reasonably good for me, not going to revert it).

BTW, thanks for committing today - tomorrow we're going into the freeze stage, so your commit, if done later, would be at risk of reverting because of different reasons;)

Sorry, one question. You added crh locale to ALL_LINGUAS. Does this locale actually exist? All locales I seen so far are 2-letters...

(In reply to comment #14)
> Sorry, one question. You added crh locale to ALL_LINGUAS. Does this locale
> actually exist? All locales I seen so far are 2-letters...
>

If you mean whether it exists in ISO, glibc: yes it's been around for a while; it's already usable in Ubuntu 9.04, Fedora (11 preview), etc., although the level of support currently varies and l10n ratio is not yet high enough.

P.S.
İf you mean po/crh.po, the way i tested it is by doing
cp po/tr.po po/crh.po
before building from source, since you insisted on not checking in po/crh.po and pulling it from TP.

Additionally, in symbols/tr you marked 2 new variants as default. I am fixing that. You know the rules...

(In reply to comment #16)
> Additionally, in symbols/tr you marked 2 new variants as default. I am fixing
> that. You know the rules...
>
Yes, "default" shouldn't have been there and was my little oversight. Alas, i'm not perfect.

Reopening bug, the build is broken with the fix to this bug. In the future, please add the bug number and URL to commit messages to make it easier for bisecting. I know it was in the changelog, that's how I got here. Commit messages are the first thing many developers see though.

From the commit msg:
"In particular, crh.po is not checked in this time, [...] so until it's pulled from TP, something like `cp po/tr.po po/crh.po` is required prior to building from source."

If a manual copy is required to build from source because something is missing then DONT COMMIT! I don't care about the reason why it's missing, but if it is required for xkeyboard-config to work, then either commit it or leave out the whole thing until the issue is resolved completely.

Oops, it seems I somehow had crh.gmo in my project, so it was built ok. I am reverting the change to configure.in - dropping crh from ALL_LINGUAS. Peter, could you please check?

works now, thanks.

(In reply to comment #18)
> From the commit msg:
> "In particular, crh.po is not checked in this time, [...] so until it's pulled
> from TP, something like `cp po/tr.po po/crh.po` is required prior to building
> from source."
>
>
> If a manual copy is required to build from source because something is missing
> then DONT COMMIT! I don't care about the reason why it's missing, but if it is
> required for xkeyboard-config to work, then either commit it or leave out the
> whole thing until the issue is resolved completely.

Based on gnome, and other projects, i'm fully aware that the committer needs to ensure that buildability is not affected. Given that you cut out the piece that stated that, I think you are aware that Sergey mentioned checking .po in as a reason for reverting in February. I was simply trying to avoid that kind of meaningless conflict again. Not checking in .po when it's sitting on my desktop, didn't sound right to me either, but i did it that way to avoid another dubious revert situation.

It also makes sense to be able to make a build with the new localization prior to code freeze, as opposed to on the day of the release. Therefore, based on this feedback, and common sense, i just committed crh.po as well, and added crh back to configure.in.

(In reply to comment #21)
> Based on gnome, and other projects, i'm fully aware that the committer needs to
> ensure that buildability is not affected. Given that you cut out the piece that
> stated that, I think you are aware that Sergey mentioned checking .po in as a
> reason for reverting in February. I was simply trying to avoid that kind of
> meaningless conflict again. Not checking in .po when it's sitting on my
> desktop, didn't sound right to me either, but i did it that way to avoid
> another dubious revert situation.

so you decided the right thing to do is to break everyone's build so you don't have to wait until the argument is resolved? if there's an argument about the code, sort the argument out first.

(In reply to comment #22)
> It also makes sense to be able to make a build with the new localization prior
> to code freeze, as opposed to on the day of the release. Therefore, based on
> this feedback, and common sense, i just committed crh.po as well, and added crh
> back to configure.in.

so you decided to commit your stuff again without feedback or acks from the maintainer? just before the freeze?

First, there's a reason why we have a maintainer. if you decide that your stuff is more important than the maintainers opinion don't be surprised if you get your stuff reverted. If you did that in one of the repositories that I maintain, I'd have removed your commit access immediately.

Political issues are non-relevant. You should nonetheless be capable of sorting things out from a technical point of view. The right thing to do is to start a discussion by inviting other ppls viewpoints and now to go over the head of the maintainer.

Look at the original comment in this bugreport. there is zero information and I don't see any attachment for proposed fixes. 5 days later you checked in code that no-one could have checked. why? did you publish the code anywhere else for review or comments?

(In reply to comment #23)
> so you decided the right thing to do is to break everyone's build so you don't
> have to wait until the argument is resolved? if there's an argument about the
> code, sort the argument out first.

OK, here it appears you are saying that i should have checked in crh.po, even though the maintainer didn't want it to be checked in.

> so you decided to commit your stuff again without feedback or acks from the
> maintainer? just before the freeze?

And here it appears that you are saying that i should heed to what the maintainer is saying.

What i gather is that you are upset that the build was broken during 15 hours, but i don't know what exactly you expected me to do: you feedback is self-contradictory.

And i don't understand what you are saying about the freeze:
if i didn't check in what i've checked in the last time, those same changes would need to be checked in during the freeze for the May 26th release; which is probably what Sergey had in mind when he temporarily removed crh from configure.in. It appears he pulls .pos from TP on the day of the release; which may be fine to previously released locales, but a newly-to-be-supported locale also requires configure.in change, which is more significant than just updating existing .po files. Are you saying that it would be better to have these changes made on the day of the release, as opposed to before the code freeze? I respectfully disagree.

I hope the fix for this bug can finally be released, and the case closed. I've never spent so much time on any other bug in my life.

(In reply to comment #24)
> (In reply to comment #23)
> > so you decided the right thing to do is to break everyone's build so you don't
> > have to wait until the argument is resolved? if there's an argument about the
> > code, sort the argument out first.
>
> OK, here it appears you are saying that i should have checked in crh.po, even
> though the maintainer didn't want it to be checked in.

either you should've:
  * not checked in the Makefile.am hunk or crh.po, or
  * checked in both the Makefile.am hunk and crh.po

if svu's against inclusion of crh.po at this point in time, why would he want a useless Makefile.am hunk to be commit which breaks the build?

> > so you decided to commit your stuff again without feedback or acks from the
> > maintainer? just before the freeze?
>
> And here it appears that you are saying that i should heed to what the
> maintainer is saying.

yes, and you should.

> What i gather is that you are upset that the build was broken during 15 hours,
> but i don't know what exactly you expected me to do: you feedback is
> self-contradictory.

not commit anything which breaks the build. if that depends on something else which you can't commit, then you have to either not commit the other bits or commit them in such a way that they don't break the build.

> And i don't understand what you are saying about the freeze:
> if i didn't check in what i've checked in the last time, those same changes
> would need to be checked in during the freeze for the May 26th release; which
> is probably what Sergey had in mind when he temporarily removed crh from
> configure.in. It appears he pulls .pos from TP on the day of the release; which
> may be fine to previously released locales, but a newly-to-be-supported locale
> also requires configure.in change, which is more significant than just updating
> existing .po files. Are you saying that it would be better to have these
> changes made on the day of the release, as opposed to before the code freeze? I
> respectfully disagree.

when they are committed is svu's decision.

> I hope the fix for this bug can finally be released, and the case closed. I've
> never spent so much time on any other bug in my life.

surprising.

As i have stated earlier, my evaluation of the buildability mishap is different, but it appears what you are saying is that i should not have added crh to configure.in relying on the following commit comment to reconcile w/ maintainer's earlier action:
"In particular, crh.po is not checked in this time, because it was one of Sergey's reasons for reverting, so until it's pulled from TP, something like `cp po/tr.po po/crh.po` is required prior to building from source."

Also, I personally would find it preferable to make a build w/ the newly supported localization before code freeze.

At this point, if everybody feels comfortable w/ changing configure.in on the day of the release, after pulling crh.po from TP, and everybody is sure that it won't be forgotten or left out (which i personally don't feel very confident about), then please feel free to undo po/crh.po addition, and addition of crh to ALL_LINGUAS in configure.in.

P.S. Frankly, i don't understand all this commotion about checking in a .po file. That's how many projects do it, and it's the only way to do it in many projects. I would also allow checking it in at least when it's tied to new changes that cannot be accomodated via TP, which is the case here. That said, .po file is probably the least significant piece here, and i will use TP to update it going forward as i was going to do anyway w/ May 11th check-in.

(In reply to comment #26)
> At this point, if everybody feels comfortable w/ changing configure.in on the
> day of the release, after pulling crh.po from TP, and everybody is sure that it
> won't be forgotten or left out (which i personally don't feel very confident
> about), then please feel free to undo po/crh.po addition, and addition of crh
> to ALL_LINGUAS in configure.in.

I thought my last check-in would actually save others some time (i guess it didn't due to more ensuing discussion), and i think no further special steps for this bug are needed. However, if there is a strong preference towards the maintainer making the changes that i made in my last check-in (on the 12th), after pulling crh.po from TP in a week or two, i can also revert my last check-in myself, if that was to be preferred to somebody else doing.

> i can also revert my last check-in myself
Just leave it as it is please. If you have time - you can help TP to complete the translation.

Created an attachment (id=26284)
Update comments for Crimean Tatar (Crimean Turkish) keyboard layouts to give Özgür Qarahan the credit due.

I focused on getting the functionality released and unfortunately overlooked giving Özgür Qarahan, who has worked with me on this, the credit due in 1 file. Please apply the patch attached to correct this oversight. His contributions have already been acknowledged in po/ and that made it into 1.6 release, but i delayed making this change in symbols/ until after 1.6 release to avoid making a non-critical update during pre-release code freeze.

P.S. To avoid any further misunderstanding, and incidents, I would highly prefer that somebody other than Sergey commits this patch. Perhaps Benjamin could do it...

Thank you.

I don't think moving 2009 to the layout name is a good idea, it might be
confusing. The line "Crimean Tatar (Crimean Turkish) layouts (2009)"
suggests that there's different layouts for every year which I doubt is the
case.

(In reply to comment #30)
> I don't think moving 2009 to the layout name is a good idea, it might be
> confusing. The line "Crimean Tatar (Crimean Turkish) layouts (2009)"
> suggests that there's different layouts for every year which I doubt is the
> case.

The Brasilian file appeared to me to be a good precedent for a similar format and a good match for this case in general:
http://cgit.freedesktop.org/xkeyboard-config/tree/symbols/br
But it doesn't use periods, whereas in this case there appears to be some benefit for 2 more sentences as comments, which makes periods useful.

Please feel free to suggest something else.

How about this for first line of comments:
Crimean Tatar (Crimean Turkish) layouts. Year added: 2009.

Perhaps it could also be one of the following:

Crimean Tatar (Crimean Turkish) layouts (2009-01-30).
Crimean Tatar (Crimean Turkish) layouts. Added: 2009-01-30.

Where 2009-01-30 could be replaced w/ 2009-02-24: the date this was first released by Ubuntu.

Quite frankly, I don't understand the need to have "year added" there
anyway. If it's for copyright assignment the year may be necessary (?), but
is it's really that important when a layout was added. This information is
avialable through the RCS anyway.

> Crimean Tatar (Crimean Turkish) layouts (2009-01-30).
> Crimean Tatar (Crimean Turkish) layouts. Added: 2009-01-30.

If we add a date, I'd vote for the second one. Sergey, any opinions?

> Where 2009-01-30 could be replaced w/ 2009-02-24: the date this was first
> released by Ubuntu.

It should be the commit date to upstream to avoid confusion. Otherwise you'd
have a reference to a date when it wasn't yet available in this repo and
then you have to start hunting down info downstream which is always a pain.

(In reply to comment #33)
> Quite frankly, I don't understand the need to have "year added" there
> anyway. If it's for copyright assignment the year may be necessary (?), but
> is it's really that important when a layout was added.
No, copyright assignment hasn't even been considered, but most other layouts have a year in comments, and some have the exact date, so the same was being emulated here.

Based on Peter's latest feedback, here are my latest preferences, in that order:
Crimean Tatar (Crimean Turkish) layouts. First published: 2009-01-30.
Crimean Tatar (Crimean Turkish) layouts. First released (by Ubuntu): 2009-02-24.
Crimean Tatar (Crimean Turkish) layouts. Year added: 2009.

The first one just says that the layouts entered the public domain on that date. The 2nd one is a fact: released w/ 1.5-2ubuntu5. Any other full date would be misleading in my opinion, because layouts have been available at least since 2009-02-24.

> This information is
> avialable through the RCS anyway.
Therefore, if there are objections to 2009-01-30, and 2009-02-24, i'd prefer just the year: because at least it would not give a misleading exact date reference. Just 2009, is not exact, but at least it's not misleading.

Created an attachment (id=26350)
Update comments for Crimean Tatar (Crimean Turkish) keyboard layouts to give Özgür Qarahan the credit due. Patch version 2.

Updated patch is ready for committing. I hope Benjamin could commit it...

If there are strong, substantiated objections to the updated comment from 2 or more people, some other variations i can suggest as the replacement of 1st line of comments are as follows:
3.
// Crimean Tatar (Crimean Turkish) layouts.
// February 2009.
4.
// Crimean Tatar (Crimean Turkish) layouts.
// Year added: 2009.

Let's not over-analyze this. The only thing consistent about variant layout comments is that most of them have a year, some have month and year, and some have full date. In other regards, the comments are essentially free-form.

Not knowing anything about the xkeyboard-config setup, I defer the commit to those who are on the project.

(In reply to comment #36)
> Not knowing anything about the xkeyboard-config setup, I defer the commit to
> those who are on the project.
>

(In reply to comment #36)
> Not knowing anything about the xkeyboard-config setup, I defer the commit to
> those who are on the project.
>
Well, i've seen a couple commits by you[1], so i thought you'd be able to commit this, especially since it deals only with comments.

Based on past experience, i do believe crh-locale-related commits should be done by somebody w/o apparent potential conflict of interest.[2]

If there are strong feelings about the format of comments, please let me know, and i'll upload another patch update.

I hope Daniel could commit it.

P.S.
[1]
http://cgit.freedesktop.org/xkeyboard-config/commit/?id=ea0269c80e8a0315efe4b4378dd6568e70c2bb8b
http://cgit.freedesktop.org/xkeyboard-config/commit/?id=29ae9f2b9a968a4cdc49e61c03dde8068326d1fd
[2]
If it applies to other professions and circumstances, it certainly is applicable in these circumstances.
P.P.S. IMO, this bug is still resolved, because the outstanding update concerns only comments. If you'd rather have a separate bug for update to comments, i'll log a separate bug.

Thanks.

(In reply to comment #37)
> (In reply to comment #36)
> > Not knowing anything about the xkeyboard-config setup, I defer the commit to
> > those who are on the project.
>
> Well, i've seen a couple commits by you[1], so i thought you'd be able to
> commit this, especially since it deals only with comments.
>
> Based on past experience, i do believe crh-locale-related commits should be
> done by somebody w/o apparent potential conflict of interest.[2]
>
> If there are strong feelings about the format of comments, please let me know,
> and i'll upload another patch update.
>
> I hope Daniel could commit it.

sergey is the xkeyboard-config maintainer, and i have full confidence in his maintenance. i don't think he has any conflict of interest whatsoever and am not going to look at myself unless he asks me to.

the conflict of interest thing is ludicrous. what happens when you have a project consisting of people from the united kingdom, the united states, russia, france, china, germany, japan, austria-hungry, the former ottoman empire, et al? everyone would have a legitimate complaint of oppression against everyone else.

also, my understanding is that 16th-century tatars opressed/murdered russians and ukranians and traded them as slaves, so if there's any conflict of interest, it flows both ways and you have no right to judge sergey.

hopefully this is the last we see of this insane political nonsense.

(In reply to comment #38)
> austria-hungry

austria-hungary, obviously. sorry.

Since it is not presently clear when the patch to update comments is going to
be committed, it appeared to make sense to log a separate bug:
http://bugs.freedesktop.org/show_bug.cgi?id=22079

I hope it's applied sometimes soon...

(In reply to comment #38)
> sergey is the xkeyboard-config maintainer, and i have full confidence in his
> maintenance. i don't think he has any conflict of interest whatsoever and am
> not going to look at myself unless he asks me to.
I think the history of the country he apparently is a subject of, and his
track record in this matter, suggest that the conflict of
interest is in fact very likely to be present, whether intentional or
subconscious, and whether ill will is present or not.
IMHO, due to past experiences he should delegate at
least Crimean Tatar (Crimean Turkish) related matters to somebody else. Also,
I do not see avoidance of conflict of interest as something that denigrates
a person, on the contrary it demonstrates good judgement and leads to better
outcomes. Slightly off-topic, FYI: some examples of excellent lawyers avoiding it can
 be seen in TV show The Guardian.

If i came from your background, i would probably have sent roughly the same
response. Unfortunately, the historical comparisons you made don't quite apply
to this case.

>
> the conflict of interest thing is ludicrous. what happens when you have a
> project consisting of people from the united kingdom, the united states,
> russia, france, china, germany, japan, austria-hungry, the former ottoman
> empire, et al? everyone would have a legitimate complaint of oppression against
> everyone else.

If you are reading this sentence, I encourage you to read the following to
gain better awareness of the conflict of interest concerns unique to Russia
with regards to languages, and why comparisons with other countries are not
applicable.

I tried to avoid going into this area before, but feel i need to raise awareness
of certain things:
1. Somewhat remote history:
1.1. it is ludicrous to force an exodus of a major part of a nation from its
native lands
1.2. it is ludicrous to execute and exile individuals for writing poems about
how they love their language and their people
1.3. it is ludicrous when a country forces dozens of nations to go through
5 alphabets in approximately 1 century
(Arabic, modified/vandalized Arabic, slightly weird Latin
(sometimes more than 1 variant in less than 10 years), Cyrillic, and Latin
again because coerced Cyrillic alphabet was the worst of them).
1.3.1. it ludicrous to use 2 letters (x and h) for 2 similar phonemes in a Latin
alphabet and then several years later to completely drop 1 of them
with the adoption of a Cyrillic alphabet.
1.4. it is ludicrous to use different letters for the same phonemes in kindred
languages just so that they look like they aren't really related:
къ-қ-к (the last one after or before back vowels)
and
нъ-ң
are just 2 simple examples, but there are many more of them.
1.5. it is ludicrous to expell the rest of a nation from its native lands and
force 46% of the expelled people to die in the process.

To be clear, Crimean Tatar language and people have suffered fr...

(In reply to comment #40)
> [huge ramble about historical wrongs snipped]
>
> And of course, I hope the bug to update comments is resolved sometimes soon.
> I need to get back to productive work, just like, i'm sure, everybody else.

please do. human history is horrible -- just look at the history of kurds, jews, poles, uighurs, tibetans, the people of timor leste and west papua, natives of any country that's ever been colonised in the past few centuries (particularly south america, my own australia, africa, north america, etc), the baltic countries post-ww2, catholic/protestant wars, israel/palestine ... people as a whole tend to be absolutely awful.

this is a technical project, and politics has no place in it. i'm very sorry to hear of plight of crimean tatars and i'm sure it's incredibly unpleasant, but pinning it on sergey and suggesting that his very nationality makes him unfit to judge your patches on a technical level will not work. it is his project, he's the maintainer, and that's not going to change any time soon unless he decides otherwise. it sucks that your account request took so long to approve, but you're hardly the only one. there have been a few that have taken similar lengths of time, or longer. oh well.

i'm out of the discussion.