The decision to use per-country approach was made on the following grounds:

1. Historically, most of the files in the symbols dir were organised on per-country basis (I guess there were some usability reasons...). I wanted to minimize the breakage of existing symbol-baseed configs.

2. There are languages with various layouts in different countries. The most important one - English, but there are several others. Putting all English variants into one file would create unmaintainable mess.

3. For countries with multpile languages it is logical to have them accessible together somehow.

4. Finally, any method, per-country and per-language, has its pros and cons. Users should be able to make selection on any basis. That's why I added languageList and countryList into base.xml. Countries and Languages are more important in metadata than in actual filesystem layout.  

On a side note, users should see US and UK in the indicator, rather than vague En.

(In reply to comment #2)
> On a side note, users should see US and UK in the indicator, rather than vague
> En.
> 
En1 and En2 when both are English is much clearer than, for instance, Fra indicating a Georgian keyboard layout, or Ma indicating a French keyboard layout, where Fra is an abbreviation for France, and Ma is an abbreviation for Morocco. The latter is very very confusing.

You were quick to dismiss this, but I hope people interested in this matter will add their opinions.

Ok, nothing stops people from adding their comments here and on the list and anywhere else...

> En1 and En2 when both are English is much clearer than, for instance, Fra
> indicating a Georgian keyboard layout, 
If that Georgian layout is used in France only - why not?

> layout, where Fra is an abbreviation for France, and Ma is an abbreviation for
> Morocco. The latter is very very confusing.
Well, it is not for me to judge. I never been to Ma.

Anyway, we're discussing here totally irrelevant point - the GUI representation. Since each layout and variant has its country and language - it is up to GUI designers to choose what to show to the user.

That's my major point. It does not really matter what to use as the basis. As long as the information in base.xml.in allows to choose any. And the rest is up to GUI.

On a side note: some people prefer to use flags to indicate layouts. This is only possible if layout is somehow bound to country.

Created attachment 33327 [details]
Mac: an example of layout flags without binding to country, etc.

Created attachment 33328 [details]
Mac: another example of layout flags without binding to country, etc.

I believe bug 23544 and perceptions of users that led to it reinforce my perception and this bug.

(In reply to comment #1)
> 1. Historically, most of the files in the symbols dir were organised on
> per-country basis (I guess there were some usability reasons...). I wanted to
> minimize the breakage of existing symbol-baseed configs.
This bug is at the moment forward-looking, so pre-existing configs shouldn't be a factor. Many projects and entire languages go through significant refactoring, and compatibility limitations every once in a while.

> 2. There are languages with various layouts in different countries. The most
> important one - English, but there are several others. Putting all English
> variants into one file would create unmaintainable mess.
I'm primarily focusing on UI at the moment, but i think config files would also be quite maintainable. If necessary, using regular locales approach could be quite suitable:
en, en-us, en-gb, etc.
For UI, I see 3 possibilities:
a. locales approach: list locales in languages list (using a single locale entry when possible, e.g. if default layouts are the same across most or all countries using that locale).
E.g. (locale names shown first, whether to show them, and whether to show language first or country first can be decided on, perhaps even on per-locale basis),
ar		Arabic
...
crh		Crimean Tatar (Turkish Q)
crh-RO	Crimean Tatar (Dobruca-2 Q)
...
en-US	English (US)
en-GB	English (UK)
...
b. country-specific sub-lists:
b.1. list common layouts under each language as menu items (e.g., common Crimean Tatar layouts)
b.2. if there are country-specific ones, add sub-list(s) with layouts specific to any countries (e.g., Romania-specific Crimean Tatar layouts)
c. Similar to Mac: keep everything in one per-language list, just prefix country-specific ones with country name (if needed, use the country with the largest number of speakers for the default layout, or perhaps even consider no default layout if the defaults are country-specific).

> 3. For countries with multpile languages it is logical to have them accessible
> together somehow.
This causes more clutter and potential for unpleasantries, and i hardly see any benefit. Except maybe for countries that try dictate other languages' alphabets, etc.: goes along with the "language is a subject of the country" notion, and some centralized control of countries over languages. Such ideas however have no place in open source software.

(In reply to comment #4)
> It does not really matter what to use as the basis. As
> long as the information in base.xml.in allows to choose any. And the rest is up
> to GUI.
Agreed. Addressing the GUI appears to be a priority at the moment. However, going forward it doesn't appear to make sense to me to adopt a locale-like approach, with config files like languageCode-countryCode. At the very least, it obvious that the UI and config files aren't really completely irrelevant to each other.

(In reply to comment #5)
> On a side note: some people prefer to use flags to indicate layouts. This is
> only possible if layout is somehow bound to country.
I disagree: The examples, attached in previous 2 comments, with flags for Inuktitut, Tibetan and Welsh are sufficient to establish that flags can be used without binding to a country. In fact, again, it is just plain dumb, forgive me my French, to show Moroccan flag for a French layout, which by the way is not Morocco-specific. The scenario is: a user in Morocco knows French; most likely he knows Arabic as well as the primary language there; he/she chooses both layouts; the indicators should help the user identify whether the layout is French or Moroccan. If both of them are MA (or Morocco flag), they don't help much and force the user to remember a number next to indicator or look up the indicator tooltip, etc. every time. Confusing, not helpful...

Finally, all of the above ideas for the UI are long-term, and perhaps even optional. At least in the short-term, the following 2 approaches might be sufficient:
i. A simple temporary partial solution as an alternative to changing the design of keyboard config UI (or xkeyboard-config for that matter), is to show layouts by language in the 1st tab, and layouts by country in the 2nd tab in the UI. This wouldn't really solve the perception and clutter issue per se, but it would make it less noticable for most users, because most would suffice with layouts by language.
ii. Simply removing layouts by country list from the UI (as largely redundant).

And any future work could be done based on the current by-language list, by adding exceptions most needed over time, such as splitting a single English layouts list into 2: English US, and English UK (if that's more preferrable).

Once again, i have spent a lot of time on this. I do not have the luxury of doing this frequently. I hope that other users play a more active role in the project, and that means not just submitting patches for fairly simple bugs, but also considering general design issues such as those brought up here.

Regards.

*** Bug 23544 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> ... Addressing the GUI appears to be a priority at the moment. However,
> going forward it doesn't appear to make sense to me to adopt a locale-like
> approach, with config files like languageCode-countryCode.
Slight correction: 
However, going forward it DOES appear to make sense to me to adopt a locale-like approach, with config files like languageCode-countryCode.

And to elaborate with a seemingly off-topic example a bit: Just as with l10n API, in Java for instance, languageCode-countryCode files would ideally extend their respective languageCode files (in the sense of inheriting common layouts, and implementing overrides if needed). Although doing manual includes as is currently done, is a similar alternative, that could be more flexible than inheritance.

But again, IHMO, this is for long-term consideration. There could be at least temporary partial solution in the short-term.

Regards.

> a factor. Many projects and entire languages go through significant
> refactoring, and compatibility limitations every once in a while.
True. We just have to manage them. There must be some, preferably automatic, upgrade path.

> I'm primarily focusing on UI at the moment, 
It is the same thing. If you look at the list of layouts-variants for the English language in gnome-keyboard-properties, you'd be shocked. At least I definitely am. There are 30 variants for that language. I do not think that average American or British user is going to dig through that mess without complaining.

> b. country-specific sub-lists:
> b.1. list common layouts under each language as menu items (e.g., common
> Crimean Tatar layouts)
> b.2. if there are country-specific ones, add sub-list(s) with layouts specific
> to any countries (e.g., Romania-specific Crimean Tatar layouts)
I do not quite understand that, I'm afraid. Actually, would you mind making some mockups, they can be very rough (you can use pencil and scanner if you like)?

> c. Similar to Mac: keep everything in one per-language list, 
That's horrible. I totally dislike that approach. Not going to discuss.

> > 3. For countries with multpile languages it is logical to have them accessible
> > together somehow.
> This causes more clutter and potential for unpleasantries, 
Just look at the variants available for the  Russia. I would say for Ossetians, Udmurts, Yakuts etc it would be quite natural to select their country first, then national variant.

> notion, and some centralized control of countries over languages. Such ideas
> however have no place in open source software.
Well, as you might have noticed, I am not going into political debates in bugzilla. I just say that if real life would require that approach - I'd have to cater for it. Currently, that's not the case, and I am not making an argument of that idea.

> Agreed. Addressing the GUI appears to be a priority at the moment. However,
> going forward it DOES appear to make sense to me to adopt a locale-like
> approach, with config files like languageCode-countryCode. At the very least,
> it obvious that the UI and config files aren't really completely irrelevant to
> each other.
Well, that would open a big Pandora's box. Theoretically, that idea would make sense, at least theoretically, just some important points:
1. We're talking about layouts, not symbols. Everything is mapped by rules - so the symbol files remain as they were, per-country. Only rules would change. At least I do not see any reason at all to change symbol files as well.
2. For some while (I am talking about years) the old schema of layouts/variants would have to supported anyway
3. What would happen to multi-lingual layouts like ca(multix)?
4. The main thing. I do not see the serious benefits from the UI POV (of course, config files would be more consistent), because at the end of the day it will be represented the same way: per-language selection, per-country selection.

> Inuktitut, Tibetan and Welsh are sufficient to establish that flags can be used
> without binding to a country. 
Well, ok, I'll explain my point. Currently gnome's indicator is typically (but absolutely unofficially!) using the external collection of flags. That collection includes flags, only flags. And that makes life very simple: user can pick any collection of flags, just unpack it into proper location - and voila (if filenames follow ISO codes, which is usually the case). If we're dropping that country-based schema, at some point the manual management of flags would be required, that cannot be fully automated.

> French or Moroccan. If both of them are MA (or Morocco flag), they don't help
> much and force the user to remember a number next to indicator or look up the
> indicator tooltip, etc. every time. Confusing, not helpful...
I am sorry - but languages have no flags. That's not my fault. And I explained above why I use country codes - in order to avoid manual flag management, that is officially forbidden in gnome, so user would have to do it himself - unless someone, not me, would start new project just for that purpose - package flags AND language "emblems".

> i. A simple temporary partial solution as an alternative to changing the design
> of keyboard config UI (or xkeyboard-config for that matter), is to show layouts
> by language in the 1st tab, and layouts by country in the 2nd tab in the UI.
I see one VERY (most?) important use case is Americans, especially the dumb ones (sorry, that is somewhat politically incorrect). The minimal path for them would be to select their country (as fast as possible, on the first tab) and press Ok. And for some other countries that use case is important as well, actually. Consider Belgium - they use French, so instead of clicking "Belgium" then "OK", they'd have to open "French" combo, then scan the combo looking for Belgian variant, then "OK".

> And any future work could be done based on the current by-language list, by
> adding exceptions most needed over time, such as splitting a single English
> layouts list into 2: English US, and English UK (if that's more preferrable).
Ghm. That would be confusing indeed - articially "split" languages (and, if you do it properly, you end up with ... right, per-country approach;)

> project, and that means not just submitting patches for fairly simple bugs, but
> also considering general design issues such as those brought up here.
Of course, thanks for bringing it up. I am willing to discuss technical and design-related matters, as long as people do not get too excited and do not use political rethorics.

(In reply to comment #11)
> > a factor. Many projects and entire languages go through significant
> > refactoring, and compatibility limitations every once in a while.
> True. We just have to manage them. There must be some, preferably automatic,
> upgrade path.
Yes, if it can be done automatically, perfect. If not, it has to be done by coding manually.

> > I'm primarily focusing on UI at the moment, 
> It is the same thing. If you look at the list of layouts-variants for the
> English language in gnome-keyboard-properties, you'd be shocked. At least I
> definitely am. There are 30 variants for that language. I do not think that
> average American or British user is going to dig through that mess without
> complaining.
That's not what i meant, but even if 30 were shown, it wouldn't be that big a deal, because they are prefixed by country, and people would look at a "sublist" for that country.
That said, you gave an example of what if all English layouts were in one file. What i meant is, the UI is the priority, which i think you agree with. Of course, i never meant having all English layouts in one file, and i agree that it would be better not to shown them all together on the UI.

> 
> > b. country-specific sub-lists:
> > b.1. list common layouts under each language as menu items (e.g., common
> > Crimean Tatar layouts)
> > b.2. if there are country-specific ones, add sub-list(s) with layouts specific
> > to any countries (e.g., Romania-specific Crimean Tatar layouts)
> I do not quite understand that, I'm afraid. Actually, would you mind making
> some mockups, they can be very rough (you can use pencil and scanner if you
> like)?
I'll post a mock-up shortly.

> > c. Similar to Mac: keep everything in one per-language list, 
> That's horrible. I totally dislike that approach. Not going to discuss.
You sound like Zine El Abidine Ben Ali of xkeyboard-configland. You do not have the right or the privilege to rule out any options as long as this is an open source project meant to be usable by any Linux desktop. You can make personal decisions and make pre-conditions like this in a separate project, that doesn't aim to sit on every Linux desktop on the planet. I'm not saying this is the best option, but it's an option and ruling it out right away is unacceptable.

> > > 3. For countries with multpile languages it is logical to have them accessible
> > > together somehow.
> > This causes more clutter and potential for unpleasantries, 
> Just look at the variants available for the  Russia. I would say for Ossetians,
> Udmurts, Yakuts etc it would be quite natural to select their country first,
> then national variant.
So now you are saying it's OK to shown 90 keyboard layouts under Russia? You just said 30 were too much for English (and yet it's one of the UIs provided)?
Or you are assuming that most of those 90 don't need keyboard layouts for them (because they being killed off)?
Well, if you absolutely have to have keyboard layouts of some languages under certain countries, do it just for those countries. Don't drag everybody else into the same mess. So another approach is to have a hybrid, of locales and countries (well, a country is also a locale, without a language) in the list.

> > notion, and some centralized control of countries over languages. Such ideas
> > however have no place in open source software.
> Well, as you might have noticed, I am not going into political debates in
> bugzilla. I just say that if real life would require that approach - I'd have
> to cater for it. Currently, that's not the case, and I am not making an
> argument of that idea.
Linux keyboard layout selection user interface is the only one among all the operating systems i know that puts political entities first for language and locale. And you have demonstrated unwillingness to depoliticize the user interface. So, your actions so far have been in favor of keeping political entities first.
I can only repeat my original thoughts on this: This causes more clutter and potential for unpleasantries, and i hardly see any
benefit. Except maybe for countries that try dictate other languages'
alphabets, etc.: goes along with the "language is a subject of the country"
notion, and some centralized control of countries over languages. Such ideas
however have no place in open source software.

> > Agreed. Addressing the GUI appears to be a priority at the moment. However,
> > going forward it DOES appear to make sense to me to adopt a locale-like
> > approach, with config files like languageCode-countryCode. At the very least,
> > it obvious that the UI and config files aren't really completely irrelevant to
> > each other.
> Well, that would open a big Pandora's box. Theoretically, that idea would make
> sense, at least theoretically, just some important points:
> 1. We're talking about layouts, not symbols. Everything is mapped by rules - so
> the symbol files remain as they were, per-country. Only rules would change. At
> least I do not see any reason at all to change symbol files as well.
It's not a priority, and can be done later, but i believe it makes sense. One reason: some Romanian users don't want to see other layouts under their country. And in general, it makes no sense to put them there. Languages cross political borders. Keyboard layouts are about linguistics and informatics, whereas countries are political entities. That said, a country without a language is also a locale (broader one than language followed by country). So in exceptional cases country-specific files and options may be needed.
> 2. For some while (I am talking about years) the old schema of layouts/variants
> would have to supported anyway
That could be done for passivity purposes, similar to deprecated features in programming languages. That shouldn't prevent having depoliticized new releases, which by the way propagate to end users who upgrade quite quickly.
> 3. What would happen to multi-lingual layouts like ca(multix)?
It appears it would belong under CA (assuming country codes are capitalized), or ca if not, at least as far as the file goes. So that might be another reason to choose a hybrid model (in the sense that some locales are language only, some are language-COUNTRY, and some are just COUNTRY).
Another alternative is mul-CA.
> 4. The main thing. I do not see the serious benefits from the UI POV (of
> course, config files would be more consistent), because at the end of the day
> it will be represented the same way: per-language selection, per-country
> selection.
What this bug is about is depoliticizing the UI: which means not using country first for all keyboard layouts, but, at most, only when it's required. 
The UI implementation could provide a country-list for filtering. If somebody needs US-specific layouts, the filter could display all languages with US-specific layouts (filtering non-US specific layouts for a matching language out, maybe with an option of filtering them back in)...
> 
> > Inuktitut, Tibetan and Welsh are sufficient to establish that flags can be used
> > without binding to a country. 
> Well, ok, I'll explain my point. Currently gnome's indicator is typically (but
> absolutely unofficially!) using the external collection of flags. That
> collection includes flags, only flags. And that makes life very simple: user
> can pick any collection of flags, just unpack it into proper location - and
> voila (if filenames follow ISO codes, which is usually the case). If we're
> dropping that country-based schema, at some point the manual management of
> flags would be required, that cannot be fully automated.
You said so yourself: unofficially. Also, the said collection, or its derivative, can include non-country based icons as well, similar to what we see on Mac. The code could try looking up the icon by full locale name (language-COUNTRY), if that's not found by language alone, and if that's not found by country (as the last resort, because really it makes no sense). Java does exactly that for resource bundles, which are frequently used for these kinds of things.

> > French or Moroccan. If both of them are MA (or Morocco flag), they don't help
> > much and force the user to remember a number next to indicator or look up the
> > indicator tooltip, etc. every time. Confusing, not helpful...
> I am sorry - but languages have no flags. That's not my fault. 
I have attached Mac screenshots with icons for languages, haven't i? Languages can have icons, period.

> And I explained
> above why I use country codes - in order to avoid manual flag management, that
> is officially forbidden in gnome, so user would have to do it himself - unless
> someone, not me, would start new project just for that purpose - package flags
> AND language "emblems".
If you insist, i will consider starting a derivative of any currently existing project to include icons for languages as well as countries. That's no excuse to not depoliticize the UI, and make it more flexible, and accomodate Romanian users, and avoid any future such cases.

> > i. A simple temporary partial solution as an alternative to changing the design
> > of keyboard config UI (or xkeyboard-config for that matter), is to show layouts
> > by language in the 1st tab, and layouts by country in the 2nd tab in the UI.
> I see one VERY (most?) important use case is Americans, especially the dumb
> ones (sorry, that is somewhat politically incorrect). The minimal path for them
> would be to select their country (as fast as possible, on the first tab) and
> press Ok. And for some other countries that use case is important as well,
> actually. Consider Belgium - they use French, so instead of clicking "Belgium"
> then "OK", they'd have to open "French" combo, then scan the combo looking for
> Belgian variant, then "OK".
In approach a. (without country-specific sublists) they wouldn't have to: 
+ English (U.S.)
+ French (Belgium)
would be in the top (and single) level of the list.
In hybrid approach they can also be on the top level of the list, and can show country without language in the UI, for countries where this is preferred:
+ U.S.
+ French (Belgium)

> > And any future work could be done based on the current by-language list, by
> > adding exceptions most needed over time, such as splitting a single English
> > layouts list into 2: English US, and English UK (if that's more preferrable).
> Ghm. That would be confusing indeed - articially "split" languages (and, if you
> do it properly, you end up with ... right, per-country approach;)
Not artificially: based on what works the best for certain cases. Most keyboard layouts can suffice with language-based list. If what you yourself said that for some layouts country-based approach appears to make more sense is true, then for those cases either full language-COUNTRY locale can be used or for some even just COUNTRY.

> Of course, thanks for bringing it up. I am willing to discuss technical and
> design-related matters
I hope that is the case.

To re-iterate problems with the current keyboard layout selection UI.
1. It's inadequate, illogical, and highly politicized by requiring each keyboard layout to be under a certain country. Romanian experience is currently the main case in point.
2. E.g. (this applies to a lot of keyboard layouts, but i'm giving a specific example), it's illogical to show abbreviation of Morocco (MA), and/or Moroccan flag, for standard French keyboard layout which can now be selected under Morocco.
3. It hides the fact that some layouts are not country-specific: such as Latin American, and Arabic. A user can't possibly tell, without looking at the source files, that, for instance, Latin American layouts with the same name under all the countries they are listed under all represent the same layout. Users have the right to and should know which layouts are country-specific and which aren't, without looking at the source file.
4. Regarding Esperanto. From wikipedia: "Esperanto is particularly prevalent in the northern and eastern countries of Europe; in China, Korea, Japan, and Iran within Asia; in Brazil, Argentina, and Mexico in the Americas; and in Togo in Africa." So, it should really be listed under at least a dozen countries. When i tried to look for it now i couldn't find it under any of the relevant countries, and finally gave up and looked it up by language. Turns out it's only listed under Brasil and Portugal. You would have to add it to a dozen countries. But when using locale-based approach, it would only need to be listed once. Again, no need to duplicate the same layout over and over, and people will know that there aren't dozens upon dozens of Esperanto layouts without having to look at the source file.

Here's a recap of all the approaches suggested so far (with the addition of hybrid approach d. and hybrid flexible approach e.).
Locale codes (mostly in first column) are meant as possible names of implementation files, but those codes wouldn't be on the UI (casing also isn't critical, just like in ISO standards, although conventionally country codes are capitalized). 
These are mockups of trees, with - showing expanded nodes, and + showing collapsed node. They don't have to be trees, but for B) and E) a tree would look better.

A) based on full locales:
+ar        Arabic
...
+crh       Crimean Tatar
+crh-RO    Crimean Tatar (Romania)
...
+en-GB     English (UK)
+en-US     English (US)

Each element here has a default layout, similar to how it's setup now.

B) country-specific sublists, when applicable (from https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/418939/comments/18):
-Language1
 |__ Common Layout1
 |__ Common Layout2
 |__ Common Layout3
-Language2
 |__ Common Layout1
 |__ Common Layout2
 |__ Country1
      |__Country1-specific layout1
      |__Country1-specific layout2
 |__ Country2
      |__Country2-specific layout1
      |__Country2-specific layout2
-Language3
 |__ Country1
      |__Country1-specific layout1
      |__Country1-specific layout2
 |__ Country2
      |__Country2-specific layout1
      |__Country2-specific layout2
+Language4

By Common LayoutX, i really mean LangY Common LayoutX, but it was getting too verbose, so it's implied...

Furthermore, the UI implementation here could provide a country-list for filtering (and metadata could provide applicable countries even for locales consisting only of language name). For example, if somebody needs US-specific layouts, the filter could display all languages with US-specific layouts (filtering non-US specific layouts for a matching language out, maybe with an option of filtering them back in)...
So the top of the UI could look like this:
Locales: drop-down	Country filter: drop-down

The filtered matches could be displayed expanded just as in the mock-up above.
Approaches for ca(multix):
1. in this case it would have to be repeated under all locales it applies to, just as Latin American is now repeated under a bunch of countries, and under Spanish.
OR
2. it could be under the standard ISO mul language code, whose description is "Multiple languages", but that's not how it's usually in other OSs.

C) Similar to Mac screenshots: keep everything in one per-language list, just prefix country-specific ones with country name

D) hybrid locales approach, allowing language, language-COUNTRY, and just COUNTRY.
+ar        Arabic
+CA	   Canada
...
+crh       Crimean Tatar
+crh-RO    Crimean Tatar (Romania)
...
+GB        UK
+US        US

This is basically a merged view of current language and country lists into 1 locale-based list.
E) Same as D, but also allowing country-specific sublists on a case-by-case basis, as needed.
+ar        Arabic
+CA	   Canada
...
-crh       Crimean Tatar
 |__ Common Layout1
 |__ Common Layout2
 |__ Common Layout3
 |__ crh-RO    Romania
      |__Romania-specific layout1
      |__Romania-specific layout2
...
+GB        UK
+US        US

If it's not an abbreviation, an adjective could be usually used: Canadian, instead of Canada.

-- Possible options to switch views:--
Plus, we all know that there can be multiple views of the same model (data). So each of these views of the keyboard layouts could be converted at run-time into each of the other views, if user chooses so. E.g., there could also be a drop-down box to convert views shown in approaches A), C), D), and E), into list with country-specific sublists, as in approach B), and so on.
And even an option to display a country-based view of this data, as long as there's metadata to support that, AND as long as it's not the default, which is the main problem of the current UI.
-- Global filter: --
In each approach, there could also be a filter for typing in a string, with matching on country or language, or full locale name, resulting in a narrowed-down filtered list as well.

If people strongly prefer seeing countries instead of languages for some locales, then approach A. is out as the default, although i do not see why that would possibly be an issue, given that a lot more users use Firefox, for instance, and have no problem selecting English/USA from a list of supported locales in preferred language UI (the same is true for Windows XP keyboard layout selection UI). If C. results in too many keyboard layouts in a serialized list, then we can skip that (at least for now). I think approaches A), B), D), and E) are all worth considering, unless somebody comes up with something better.

P.S. As i wrote last time, I can't dedicate a lot of time to this, but will try to pitch if there's a sincere effort in the right direction.

*** Bug 23544 has been marked as a duplicate of this bug. ***

(In reply to comment #12)
> (In reply to comment #11)
> > That's horrible. I totally dislike that approach. Not going to discuss.
> You sound like Zine El Abidine Ben Ali of xkeyboard-configland.

And you sound like someone with no sense of perspective, with whom having any discussion is completely pointless.

> You do not have
> the right or the privilege to rule out any options as long as this is an open
> source project meant to be usable by any Linux desktop. You can make personal
> decisions and make pre-conditions like this in a separate project, that doesn't
> aim to sit on every Linux desktop on the planet. I'm not saying this is the
> best option, but it's an option and ruling it out right away is unacceptable.

Actually, he does have that right.  He's the maintainer, remember.  He also has the right to rule out changing all the files to rot13-encoding, rewriting XKB in XML and using an XSLT stylesheet to generate the keyboard maps, changing the build system to ant, etc, because it's his project.  If you don't like it, then fork it, and the distributions will immediately switch over to your project instead.

_That_ is the freedom that open source offers.  Not the freedom to let people railroad the maintainer into making only the decision they are happy with by comparing making a decision about keyboard layout UI, to a dictator who murdered any number of his own civilians.

> Keyboard layouts are about linguistics and informatics,
> whereas countries are political entities.

Care to explain to me the difference between US and UK layouts then? Furthermore, care to explain how Australia (which speaks en_GB) uses the US layout? Also, can you explain the difference between French and French-Canadian layouts? French and Belgian Walloon? German and Swiss German? Spanish and Latin American?

> > > French or Moroccan. If both of them are MA (or Morocco flag), they don't help
> > > much and force the user to remember a number next to indicator or look up the
> > > indicator tooltip, etc. every time. Confusing, not helpful...
> > I am sorry - but languages have no flags. That's not my fault. 
> I have attached Mac screenshots with icons for languages, haven't i? Languages
> can have icons, period.

So your way of 'depoliticising' the UI is to use flags, one of the most intensely political symbols out there? Did you even see what happened with GNOME? How do you plan to represent the Moroccan flag -- current or pre-revolutionary (careful how you answer - you wouldn't want to be like Ben Ali)? How would you represent traditional Chinese, with the Taiwanese flag? How about Tibet? West Papua/Irian Jaya?

> > And I explained
> > above why I use country codes - in order to avoid manual flag management, that
> > is officially forbidden in gnome, so user would have to do it himself - unless
> > someone, not me, would start new project just for that purpose - package flags
> > AND language "emblems".
> If you insist, i will consider starting a derivative of any currently existing
> project to include icons for languages as well as countries. That's no excuse
> to not depoliticize the UI, and make it more flexible, and accomodate Romanian
> users, and avoid any future such cases.

At least if you forked xkeyboard-config, I wouldn't have to read constant and lengthy 'making any decision I don't agree with is literally violating my freedom' diatribes in the morning.

> > > And any future work could be done based on the current by-language list, by
> > > adding exceptions most needed over time, such as splitting a single English
> > > layouts list into 2: English US, and English UK (if that's more preferrable).
> > Ghm. That would be confusing indeed - articially "split" languages (and, if you
> > do it properly, you end up with ... right, per-country approach;)
> Not artificially: based on what works the best for certain cases. Most keyboard
> layouts can suffice with language-based list. If what you yourself said that
> for some layouts country-based approach appears to make more sense is true,
> then for those cases either full language-COUNTRY locale can be used or for
> some even just COUNTRY.

As I said before, it gets confusing for places like Australia, where we speak en_GB but use the en_US layout.  How would you represent that with a flag?

For bonus points, answer the same question for New Zealand, where using an Australian flag could be seen as insensitive.

> 4. Regarding Esperanto. From wikipedia: "Esperanto is particularly prevalent in
> the northern and eastern countries of Europe; in China, Korea, Japan, and Iran
> within Asia; in Brazil, Argentina, and Mexico in the Americas; and in Togo in
> Africa." So, it should really be listed under at least a dozen countries. When
> i tried to look for it now i couldn't find it under any of the relevant
> countries, and finally gave up and looked it up by language. Turns out it's
> only listed under Brasil and Portugal. You would have to add it to a dozen
> countries. But when using locale-based approach, it would only need to be
> listed once. Again, no need to duplicate the same layout over and over, and
> people will know that there aren't dozens upon dozens of Esperanto layouts
> without having to look at the source file.

Wikipedia estimates that Esperanto has 200-1000 native speakers.  I don't think it's really that important.

Daniel, do not waste your time. Really.

I am closing this one. There is enough meta-information in base.xml to provide any kind of browsing/searching (see GNOME3 UI for example).

JFYI, the variant descriptions are going to be reviewed - and some of them are going to change dramatically, so there will be less visual "dependency" on the country. For example "USA - English International" could become "English - American, International". But that is the work in progress with GNOME (pushed by GNOME3 UI).

Structurally, I am not going to do chane the current structure. Obviously, not just because one emotional person is asking for it.

(In reply to comment #15)
> Care to explain to me the difference between US and UK layouts then?
> Furthermore, care to explain how Australia (which speaks en_GB) uses the US
> layout?
Have you read comment 13? Tree nodes for UK and US:
+UK
+US

There are less implicit approaches for Australia, but if Australia is happy with the status quo, approaches D) and E) would leave it as is.
If you are truly interested in discussing specifics, i'm ready, but so far there's been nothing here but ruling approaches out without a discussion. That is prejudicial, and not in the spirit of open source.

In general, all other OSs successfully represent keyboard layouts without having to choose a country first for each and every language (variant). That proves that not only it's possible, but that most implementations find it more appropriate. And claiming here that all of them are wrong, and this one project is right is ludicrous, considering that the current design has already lead to a conflict between interests of different ethnic groups.

> > > I am sorry - but languages have no flags. That's not my fault. 
> > I have attached Mac screenshots with icons for languages, haven't i? Languages
> > can have icons, period.
> 
> So your way of 'depoliticising' the UI is to use flags, one of the most
> intensely political symbols out there?
Daniel, you are mischaracterizing or haven't really understood what i wrote. You can quote me if you wish. It looks you didn't read, but just skimmed.
I never focused on, and insisted on icons or proposed to make them required. I just said there wouldn't be any difficulties having icons for languages, as well as countries (as extra, optional, if needed manually-installed features as they are now: in fact i haven't said anything about how they could be shipped and talked in terms of an equivalent approach to the current approach, but with icons for languages, and locales, and countries). Mac UI proves that it's possible to have icons for languages as well as countries. I wrote "Languages can have", and you are mischaracterizing it as everything "must have".

> At least if you forked xkeyboard-config, I wouldn't have to read constant and
> lengthy 'making any decision I don't agree with is literally violating my
> freedom' diatribes in the morning.
Again, you misunderstood. This what Sergey said: 'unless someone, not me, would start new project just for that purpose - package flags AND language "emblems"'.
And i said "If you insist, i will consider...".

It's unfortunate that noone so far has been willing to discuss ways of avoiding artificially created, and unnecessary conflicts between interests of different ethnic groups.

My understanding of an open source project is a project based on mutual respect, where people of one ethnic background aren't put into a position to want or need or have to delete or disappear feature(s) of the software pertaining to people of another ethnic background. Xkeyboard-config now is not such a project.

Generally speaking this bug has been successfully resolved thanks to the good people of the Gnome community that drove the improvements:
https://bugzilla.gnome.org/show_bug.cgi?id=640772
http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage

Recently, improvements consistent with the above have also been made following bugs logged to xkeyboard-config at freedesktop.org (e.g., bug 35653).

However, what has been done for almost all layouts has not been done for Crimean Tatar layouts yet, so I'm providing a patch for that in a separate bug...

Great. I am happy if you're happy.