Comment 18 for bug 418939

1. I have mentioned this upstream earlier, but here's an example of a logical locale-based approach to layouts:

-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

This is a mockup of a tree, with 2 recursively expanded nodes, and 1 collapsed node. E.g., by Common Layoutx, i really mean Langy Common Layoutx, but it was getting too verbose, so it's implied...

And, in terms of implementations, as i've mentioned before, i believe locale-based files would be ideal:
lang1
lang2
lang2-Country1
lang2-Country2
lang3
and so on.

Furthermore, 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)...

2. Alternatively, there could simply be a single list of locales, just as the implementation files above, and once a locale is chosen, all layouts for it are shown, including common ones, if they aren't overriden. This would also be a very clean approach.

Anyway, i don't have much time for this: this is just a few quick thoughts on the matter. This is the kind of discussion that needs to take place. Mac and Windows need to be analyzed to take the best from them, and improve further...

Regards.