Crimean Tatar (Crimean Turkish) layouts need to be added.
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 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, i do not have any trust in your ability and even willingness to handle this matter objectively, to say the least, and you might well have ulterior motives.
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 much smaller populations 4. Romania requires customizations and thus is not up to discussion. 5. Uzbekistan and Turkey populations are very significant, and therefore are not up to discussion either. 5.1. The stats in Wikipedia in this regard can't really be trusted, partly because data for some countries isn't really known, and partly because there are other much different stats around. For instance, http://www.joshuaproject.net/peoples.php?rop3=102312 shows that Crimean Tatar (Crimean Turkish) populations of Ukraine and Uzbekistan are essentially equal in number, and it shows that the population in Turkey is twice as big as what Wikipedia shows in its minimalistic guesstimate. The same article that you mentioned also mentions the number of 5 million Crimean Tatars (Crimean Turks) for Turkey: search for "There are 5,000,000 people". Elsewhere, Wikipedia itself also mentions a number of 1 million for Turkey: http://en.wikipedia.org/wiki/Crimean_Tatar_diaspora 5.2. Some estimates used in Western sources, in Turkey and in Russian media indicate that there are millions (up to 6 million) of Crimean Tatars (Crimean Turks) in Turkey. Here are some such references: 5.2.1. 3-to-5 million: http://books.google.com/books?id=S8YakB12QEUC&pg=PA227&lpg=PA227&dq=Crimean+Tatars+in+Turkey+million&source=bl&ots=1221M6j2Oj&sig=yh8jFCinmDHpiHHq8EKdnZ7k3Qg&hl=tr&ei=_cjSSafAD4yKtAPWlIn1Cw&sa=X&oi=book_result&resnum=3&ct=result 5.2.2. 6 million: http://www.iccrimea.org/scholarly/jankowski.html 5.2.3. 5 million: http://www.answers.com/topic/crimean-tatars 5.2.4. Mentioning of 1.25 million fleeing to Turkey in 1917-1918: http://www.hunmagyar.org/turan/caucasus/krim.html 5.3. Russian media, including Russian media in Crimea itself, has mentioned the number of 5 million Crimean Tatars (Crimean Turks) in Turkey, as referenced here: http://www.google.com/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Fwww.kirimdernegi.org%2Fistanbul%2Fbahcesaray%2Fpdf%2FBahcesaray-52.pdf&ei=IM3SSerVBqLitAOG18n5Cw&usg=AFQjCNEpA8lCAO0izTcUHMHk-7lGKJNLlw&sig2=dlOAK3v67fcAI67T4iI-AA ----------- To wrap up, none of the 4 countries can be dismissed. > 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. a. I never said i'm not interested in discussion. I said you acted (and frankly you continue to act) showing that YOU are not interested in discussion. b. It must take a great lot of nerve to ignore this bug for 1.5 months, not answer on one's procedural violations and hostile behavior, and then on the first post after that, close the bug as Invalid. Now let's see what i said: "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 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, i do not have any trust in your ability and even willingness to handle this matter objectively, to say the least, and you might well have ulterior motives." Your recent actions reinforce this impression, so i still "do not have any trust in your ability and even willingness to handle this matter objectively". Given this situation, i'm not sure yet how this issue will be resolved, but i'm 100% sure that you do not have any right to close this bug as Invalid. It now appears to be quite clear that there is no point in trying to contribute here in this environment at this time, and frankly i don't have any more time to waste on you (after all of my time that you have wasted), given that i can actually peacefully and effectively contribute in various other endeavors of which there are so many. However, one way or another this issue will have to be resolved, and only then can this bug be closed. The solution to this issue will probably require participation of objective persons. In an objective, peaceful and constructive environment, i am ready to discuss this issue with objective and constructive people, and unfortunately you are not such a person.
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 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).
> 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 attachment 26284 [details] [review] 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 attachment 26350 [details] [review] 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 from all of the above tragedies. But items 1.2, 1.3, and 1.4 also apply to many other nations and their languages, so unfortunately it's been a habitual state of affairs in that country. 2. Recent history: 2.1. it is ludicrous for a country to outlaw any alphabet but the Cyrillic alphabet for the nations that it conquered (i.e., to actually make a law outlawing any non-Cyrillic alphabets). 2.2. it is ludicrous for a country to assassinates people that its totalitarian rulers don't like, even if those people fled the country (why it's relevant: no sharp opposition of "party line" is tolerated): 2.2.1. multiple assassinations and court convictions in Qatar 2.2.2. assassination of Alexander Litvinenko w/ polonium 210 in London. ... All of these things are ludicrous, but more than that they are tragic, outrageous, and unacceptable. Also, no other country in the world has such a track record of totalitarian language-torturing and mind control: especially not for tragedies mentioned in items 1.3., 1.4. and 2.1. China might be the only one in the list you mentioned, and in the known universe for that matter, that has some similar history, but it probably has not been as abusive: AFAIK, they changed Uygur alphabet from Arabic to Latin, then back to the same or modified Arabic; and there's probably a lack of freedom for Uygurs to decide on the matter on their own. Any comparison to France and the U.K., or the U.S. and Japan, etc. isn't applicable: because one of them doesn't rule or have claims against the territory of the other (see: naval base lease termination in 2017, and Ukraine's concern about possibility of conflict due to other side not leaving), because they haven't practised totalitarian torturing of the other's language, and for many other reasons... So, the list of countries you mentioned isn't usable for a comparison here: in fact, i don't think you could find totalitarian language-torturing like that anywhere in the known universe. Therefore, Russia is obviously and unfortunately a unique from that perspective country. And even if it repeals its silly law, revealing the "party line" about forcing everybody to use Cyrillic alphabet (read hatred of Latin alphabet, 2nd-class treatment of other languages), one would need to wait a century to see what the practices really are on the ground before concluding that language-torturing is over. I'm not accusing anybody in xkeyboard-config of directly having anything to do w/ any of the above tragedies, because i don't have any evidence to prove it, but excuse me if i may say that one's being a subject of that country may at the very least intentionally or subconsciously predispose one to not being quite fair in dealing with the matters of a language of the people which that country has been oppressing for centuries. Arguably, the facts like the above alone would only raise the potential for and probability of conflict of interest. But i think Sergey's actions have been in line with that country's historical and present actions as it applies to languages: a. he was unresponsive in the matter of opening the account: it took 1.5 years to hear from him, included in that are 4 months after he was pinged by admins. b. his very first action on the matter was to revert the layouts: b.1. without any discussion. b.2. without any basis. b.2.1. the only rule that wasn't strictly followed had to do w/ spelling inconsistency, which as i pointed out existed in the code in the repo anyway, and didn't justify a revert (unless it takes place in a comedy about communism-style redtape): b.2.1.1. One similar inconsistency that i pointed out (Dvorak, Polish quotes on key "1/!"): http://bugs.freedesktop.org/show_bug.cgi?id=19730#c8 b.2.1.2. It was addressed ("fixed" doesn't quite apply here cause nothing is broken) by Sergey w/o a revert here: http://cgit.freedesktop.org/xkeyboard-config/commit/?id=ec657924a20dac8733650c1109b53f9600783e3a c. Then, after a month and half of not following up, and not justifying his abusive actions, his first action was to close the bug as INVALID, again w/o any discussion. d. When all is said and done, it took him 3 months after the code was submitted and all of the above destructive behavior before his first constructive feedback. By then, the layouts had already been released by Ubuntu, which i pursued in despair over Sergey's actions, and the train was unfortunately a little off track due to his earlier mentioning .po as a reason for revert, and the enusing misunderstanding, etc. d.1. Btw., having .po (importantly: of a new locale) in the build, allowed me to come across the following bug during testing, which would have been fixed in time for the last release if the matter was dealt w/ constructively from the very beginning: http://bugs.freedesktop.org/show_bug.cgi?id=21924 IMHO, it doesn't take a rocket scientist to see a pattern and consistency in the 2 lists... > > also, my understanding is that 16th-century tatars opressed/murdered russians > and ukranians and traded them as slaves, I'm not a historian, but a lot of that is propaganda. I'm sure there have been injustices, but on balance they just don't compare: for one thing, as it relates here, no Tatar state, including Crimean Khanate, ever even thought of changing or controlling or imposing on anybody's alphabets, or religion for that matter, even when they could do so. > so if there's any conflict of > interest, it flows both ways and you have no right to judge sergey. For it to flow both ways i'd need to have reverted something that deals w/ another language w/o any discussion (and do so based on dubious excuses), etc. That is not the case, and i have no desire to torture or interfere w/ anybody's language. And if the places were in fact reversed, and somebody told me there is a substantial potential for conflict of interest, i'd simply delegate it to somebody more clearly neutral. Like i said, it doesn't denigrate a person, just like a lawyer stepping out of a room to avoid an interaction due to a conflict of interest doesn't denigrate that lawyer: quite the opposite. > > hopefully this is the last we see of this insane political nonsense. > I have presented my case more fully above. If that still isn't convincing enough about the potential conflict of interest, there doesn't appear to be anything else i can do. To be clear, if there is a syntax error, or broken feature, obviously anybody can and should fix it. If it's a useful contribution without interference, imposition, and destructive behavior it should be welcome. Most importantly, IMHO, the goal is not a gesture per se, but the absence of interference, imposition, and destructive behavior in the matters concerning a language, by people who aren't related to it, especially by people who are subjects of the country with uniquely unacceptable historical and present policies that have caused so much tragedy both for the language and the people that hold it dear. I hope this overly long message served, if nothing else, to raise awareness of the possibility of conflict of interest, in case similar situations ever arise in the future, so that the red-line of no interference, and no imposition is not allowed to be crossed. That said, I sincerely hope that it will never happen, for any language whatsoever. 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.
(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.
I will provide a patch later but this message is mostly for Reşat, as probably no one else is interested... Please excuse me from polluting FDo's Bugzilla and your mailbox with this final overly long clarification of facts from me as I'm also trying to clear my name in response to some accusations. Dear Reşat, I admire your persistence and idealism, but you'll have to accept the realities here and stop fighting windmills: 1. Crimean Tatar is on the verge of extinction in Romania. Everywhere you look on the Internet they discuss among them in Romanian. As I found on the Softpedia forum and in other places, the Tatars are a proud nation and they rarely recognize this in public. However, besides all the sites[1] and blogs[2] that acknowledge this and call for immediate action to salvage the language, here's a rare sincere testimony from a Romanian Tatar on a blog[3]: "Marea majoritate a tatarilor/turcilor din Dobrogea abia daca stiu sa lege doua propozitii. In plus limba care se vorbeste este foarte limitata si neomogena. Ne place sau nu limba de facto este romana." It says: "The vast majority of Tatars/Turks in Dobrogea can barely articulate two phrases. More so, the spoken language is very limited and non-standard". Yes, I know this is a rather extreme point of view, but it counterbalances your picked citations pretty well! 2. There is no keyboard STANDARD for a Crimean Tatar latin layout, let alone a Romanian one. This is no excuse for you to include every possible combination and pollute the Romanian XKB file with four layouts. I don't care what's used in Turkey in this specific case, I care about what would be the most useful layout for Romanian Tatars in the improbable case they'll need to write in their native language in X.Org. As you are probably not aware, the default layout for Romania is a technical one, very similar with the Alt-Q Turkish variants. Yes, it is mostly used by programmers, web designers and the like, but they make up the bulk of X.Org users so they are happy that their layout of choice is the default one. More so, in 2004 this layout was included in the official Romanian standard. Any X.Org Romanian Tatar user would most probably be familiar with this layout, so an Alt-Q Tatar layout would be the most adequate layout for him/her. 3. Now to correct your view of history... Northern Dobruja has always been the land of Romanians and their ancestors. In the XIV century, when the Turkish Empire has reached this land for the first time, it was part of the Romanian Voivodate of Mircea I of Wallachia[4], here's a map to visualize it better[5]. Even under Turkish rule, Romanians have always been the bulk of population in Northern Dobruja, the part now included in Romania, the demographic data from the Ottomans prove this also[6]. 4. In regards to our attitude to Tatars... Despite all the damage they have inflicted to the Romanian people in the Middle Ages and the associated negative connotations of their name in the Romanian language[7], Romania as a modern state has always been a safe haven for Crimean Tatars. This minority has had virtually everything it needs to protect its language and traditions in Romania over the years, in marked contrast with the situation in Crimea and Southern Dobruja. I, as Romanian, have no interest whatsoever in oppressing Romanian Tatars. I have tried for weeks to contact Romanian Tatars (I sent mails, I wrote on blogs, I wrote in forums) to inform myself in regards to the curious situation of four Crimean Tatar layouts in the Romanian XKB file, but few Romanian Tatars are willing to discuss this, thus my repeated appeals for answers on the Softpedia forum. Me challenging some of their answers doesn't qualify as anything other than theoretical dispute. Whether you like the situation of Crimean Tatar in Romania or not, I'm afraid you'll have to accept it. We have reached a conclusion here and it was much influenced by you. I'm not willing to discuss this any further with you. I haven't seen any new arguments from you in the last posts. They are basically the same rehashes and a few marginal points that I was already aware of. Your arguing is VERY unproductive and I'm fed up with your accusations and with your Turkish Tatar idealistic view of history and everything. 1. http://www.tatar.ro/articole/evolutia_bilingvismului_tataro_roman_in_perioada_actuala_in_dobrogea.php 2. http://asanvein.weblog.ro/?p=985247 3. http://webcache.googleusercontent.com/search?q=cache:rmaFckKLlAEJ:joienegru.blogspot.com/2009/08/ce-penibili-sunt-tatarii.html 4. http://en.wikipedia.org/wiki/Mircea_I_of_Wallachia 5. http://en.wikipedia.org/wiki/File:Tara_Rumaneasca_map.png 6. http://en.wikipedia.org/wiki/Dobrogea#Demographic_history 7. http://dexonline.ro/definitie/tătar
Oops, excuse me one more time, this was meant for bug #23544 :D
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.