The field there sets a language/country pair. If you select "English(Israel)" you get fo:language="en" and fo:country="IL".

You need this information, for example, to select the appropriate dictionaries, thesauri, hyphenation rules, and AutoCorrect entries.

 (In reply to Eyal Rozenberg from comment #0)
> 
> Also, with the inflation of choices, we have a dozen kinds of English which
> aren't about a different language - mostly a waste of space, and making it
> easier to make choices with misleading/invalid information. Same goes for
> Arabic in the RTL/CTL group: 15 different kinds or so.

Are you sure there exists items, which are not considered somewhere? For example, you can define your own AutoCorrect entries for each of the items in this 'Language' drop-down list.

(In reply to Regina Henschel from comment #1)
> The field there sets a language/country pair. If you select
> "English(Israel)" you get fo:language="en" and fo:country="IL".
> 
> You need this information, for example, to select the appropriate
> dictionaries, thesauri, hyphenation rules, and AutoCorrect entries.

... none of which are relevant when choosing a _font_. Changing a font should have no effect on dictionaries, thesauri, hyphenation or autocorrect.

So, clearly, the choice of country should be placed somewhere closed to where we control or configure the use of these features.


> Are you sure there exists items, which are not considered somewhere? For
> example, you can define your own AutoCorrect entries for each of the items
> in this 'Language' drop-down list.

Even if choosing a country is significant in some contexts, there is rarely a need to choose a pair from the Cartesian product of language x country (as opposed to local language variants).

So you suggest to have a separate dropdown for Country in the font tab, probably one for all three groups?

(In reply to Heiko Tietze from comment #3)
> So you suggest to have a separate dropdown for Country in the font tab,
> probably one for all three groups?

I can't suggest that, because the whole situation is invalid: Font selection has nothing to do with language or country selection.

If we did that, however, it would resolve this particular bug, while maintaining, perhaps even underlining, the bug of having country/locale selection in the wrong place. I suppose that would be an improvement over the current state of affairs.

As for the deeper solution... I'll first say that I think there should be a deep paradigmatic discussion about these issues. Possibly even deeper than at the LibreOffice app level. I'll then say that maybe it makes sense for the choice of locale to be outside the app, tied to the choice of keyboard layout. Because there's no reason the user should not be able to enter text in multiple locales in the same language group, regardless of font; and that action is not specific to LO, but does seem to tie nicely with the desktop-environment-level choice of keyboard layout. And as for fonts and font families - the dialog should allow the specification of a font-set, as discussed in bug 151215: A mapping from languages to fonts with fallbacks for languages not explicitly specified or when glyphs are missing etc.

(In reply to Eyal Rozenberg from comment #4)
> (In reply to Heiko Tietze from comment #3)
> > So you suggest to have a separate dropdown for Country in the font tab,
> > probably one for all three groups?
> 
> I can't suggest that, because the whole situation is invalid: Font selection
> has nothing to do with language or country selection.

Not a topic for UX then (likely a duplicate).

(In reply to Eyal Rozenberg from comment #4)
> I'll then say that maybe it makes sense for
> the choice of locale to be outside the app, tied to the choice of keyboard
> layout. Because there's no reason the user should not be able to enter text
> in multiple locales in the same language group, regardless of font; and that
> action is not specific to LO, but does seem to tie nicely with the
> desktop-environment-level choice of keyboard layout. 

I disagree with that point. I use the Spanish keyboard layout to write not only on Spanish, but also Italian and English without problems. Thanks to its dead keys layout + AltGr combinations the Spanish keyboard can be perfectly and easily used to write also in French, German and most languages that rely on the Latin script*, so I don't need to learn new keyboard layouts to use different languages, just use the correct diacritics combination. In my case and for many people keyboard language does not correlate with the language being written. 

Also, there is an indirect, but important, relation between language settings and fonts: languages using non Latin scripts. There are really few pan-unicode fonts out there so if you change language to a non Latin script most of the time you must change fonts also. 

That said, yes, the current situation is not optimal, but I'm not that sure how to fix it.

---

* The Linux version of the Spanish keyboard layout allows to write characters such as ß, ø, ł, â, å, etc.

(In reply to Heiko Tietze from comment #5)
> Not a topic for UX then (likely a duplicate).

The UX topics seem to be:

* What should be the user experience for setting languages and/or locales for dictionaries, thesauri, hyphenation rules, and AutoCorrect entries?

* User should not be deceived by a request to select a "language" when they're actually selecting a locale, or a language-country pair.

(In reply to Regina Henschel from comment #1)
> You need this information, for example, to select the appropriate
> dictionaries, thesauri, hyphenation rules, and AutoCorrect entries.

... and also for formatting numbers/dates (e.g., in tables, or in fields...), so yes, these are locales.

(In reply to Eyal Rozenberg from comment #2)
> ... none of which are relevant when choosing a _font_. Changing a font
> should have no effect on dictionaries, thesauri, hyphenation or autocorrect.
> 
> So, clearly, the choice of country should be placed somewhere closed to
> where we control or configure the use of these features.

... which is, as *you* suggested, not an issue that we should track here ;)

Unless you suggest to split setting *language* as property of text, and *all other aspects of a locale* to someplace else? I would assume that when we say "language is a property of text", we actually mean "language and other locale preferences are properties of text". If so, then all this is just part of overall problem. Otherwise, I'm afraid, it would require some confusing UI, but I can be wrong...

(In reply to RGB from comment #6)

Let me first point out that this thread of discussion we're having is independent of this bug...

> (In reply to Eyal Rozenberg from comment #4)
> I disagree with that point. I use the Spanish keyboard layout to write not
> only on Spanish, but also Italian and English without problems.
>
> Thanks to
> its dead keys layout + AltGr combinations the Spanish keyboard can be
> perfectly and easily used to write also in French, German and most languages
> that rely on the Latin script*, so I don't need to learn new keyboard
> layouts to use different languages, just use the correct diacritics
> combination. In my case and for many people keyboard language does not
> correlate with the language being written. 

I'm not suggesting you be forced to use a keyboard layout you don't like. The question is of the mechanism you use to express the fact that "I'm writing Italian now", "I'm writing Spanish now" etc. Sometimes, you don't care about expressing this fact; but you do need to express it to use features like spelling check / dictionary, hyphenation etc. what I'm saying is that:

* It makes sense for this mechanism not to be application-specific - just like setting the keyboard layout is not an application-specific thing.

* It would be convenient to piggy-back onto the keyboard layout setting mechanism(s). That does not mean keyboard layout chosen = language used; but the same dialogs, utilities, task bar / panel icon etc we use for setting the keyboard layout should also be used to set the input's locale / language + country. So you should be able to say "I'm now going to enter text in the English language, localized for Australia, and using a Spanish keyboard layout".


> Also, there is an indirect, but important, relation between language
> settings and fonts: languages using non Latin scripts. There are really few
> pan-unicode fonts out there so if you change language to a non Latin script
> most of the time you must change fonts also. 

That's why we don't set fonts, we set font-sets. Quoting from the example in bug 151215, Comment 19:

            <a:minorFont>
                <a:latin typeface="Calibri" panose="020F0502020204030204"/>
                <a:ea typeface=""/>
                <a:cs typeface=""/>
                <a:font script="Jpan" typeface="游明朝"/>
                <a:font script="Hang" typeface="맑은 고딕"/>
                <a:font script="Hans" typeface="等线"/>
                <a:font script="Hant" typeface="新細明體"/>
                <a:font script="Arab" typeface="Arial"/>
                <a:font script="Hebr" typeface="Arial"/>
                <a:font script="Thai" typeface="Cordia New"/>
                etc. etc.

this is how it's done in MSO. Unfortunately, LO's font-sets only have 3 fonts in a font-set: western, RTL-CTL and CJK. But this deficiency is acknowledged and - at some point - will be rectified.

(In reply to RGB from comment #6)
> I disagree with that point. I use the Spanish keyboard layout to write not
> only on Spanish, but also Italian and English without problems.

I do not quite see what you are objecting to. AFAICT, there was no suggestion to *force* anything. The functionality to tie the locale to system input language is *already there*, since OOo, and works on Windows, and now also on Qt5. It would definitely be also desirable to implement it on other platforms. Yet, there is (and was almost the same long) a "Ignore system input language" setting in options, which allows one to configure it.

(In reply to Mike Kaganski from comment #8)
> Unless you suggest to split setting *language* as property of text, and *all
> other aspects of a locale* to someplace else? I would assume that when we
> say "language is a property of text", we actually mean "language and other
> locale preferences are properties of text".

Yes, indeed.

> If so, then all this is just part of overall problem.

It's a part of the overall problem, but not "just" a part of the overall problem.

If there are planned efforts to address the overall problem, then let's not bother with this bug since it will go away soon. But since those efforts are very significant, and are not in our immediate future, we can improve the current situation by splitting "language" and "country", or "language" and "locale" so that the choice of language defines the locale options. That would not make the general problem worse, but would make selection easier and would be less confusing.

(In reply to Eyal Rozenberg from comment #11)
> since those efforts are
> very significant, and are not in our immediate future, we can improve the
> current situation by splitting "language" and "country", or "language" and
> "locale" so that the choice of language defines the locale options. That
> would not make the general problem worse, but would make selection easier
> and would be less confusing.

I disagree. I do not see a real benefit of such a split. To the contrary, I can see how that would bring more confusion.

Currently, users just make the choice in the only place where it makes sense *at this moment*. Because the current implementation reflects the *file format* and *document model* - that locale is a property of character formatting. Well, the font tab is just something that we could change - fine; let's put it to Position or Borders tab ;) Jokes aside, this is not important on which tab the locale is set, since it wouldn't make sense anywhere on a *formatting* dialog without your proposal.

But as soon as you suggest to move it elsewhere, as an "interim" measure, you break the visual link with character formatting, which still exists internally, but introduce such a link (invisibly) at any other place where you put the setting to.

(In reply to Mike Kaganski from comment #12)
> Currently, users just make the choice in the only place where it makes sense
> *at this moment*. ... But as soon as you suggest to move it elsewhere, 
> as an "interim" measure

I actually suggest a split without a move as the interim measure. So, instead of:

Language: [ selection V ]

we would have something like: 

Language: [ selection V ]
Country:  [ selection V ]

or 

Language: [ selection V ]
Locale:   [ selection V ]

with the bottom list only having items corresponding to the top list selection.

(In reply to Eyal Rozenberg from comment #13)
> I actually suggest a split without a move as the interim measure.

Apologies, I misunderstood you.
Then:
1. I do not see upsides of having two controls instead of one:
  * it will clutter the UI;
  * it will require additional effort to create respective programming logic;
  * IMO, there are ~no users who would prefer two controls over one, and also I don't believe that people spend more time scrolling through the ~longish list now than they would do with two shorter lists;
  * new class of user errors will appear, with people forget to set country where important;
  * new kind of complaints will appear from users whose attention gets attracted to the sudden change, who will start to ask why (why the change, and why the country matters here, when this didn't even cross their mind before).

2. But ... my opinion is not strong in this specific case. If UX agrees, and someone volunteers to this, then why not.

(In reply to Mike Kaganski from comment #15)
> 2. But ... my opinion is not strong in this specific case. If UX agrees, and
> someone volunteers to this, then why not.

The advantage of a logically more precise UX stands against the UI downsides, I wouldn't change it. Even if implemented the summary is claiming that font selection should not have any choice of language. => WF

(In reply to Mike Kaganski from comment #15)
> (In reply to Eyal Rozenberg from comment #13)
> 1. I do not see upsides of having two controls instead of one:
>   * it will clutter the UI;

Well, arguably the UI is already cluttered with an irrelevant field. But adding a drop-box is a price to pay, yes.

>   * it will require additional effort to create respective programming logic;

I don't think that this is a valid kind of argument... it's like saying you shouldn't go anywhere because that would take time.

>   * IMO, there are ~no users who would prefer two controls over one,

So, here's the crux of the disagreement. We're talking about users who actually use the current control (other users have no preference obviously). Of those users - do they really want the whole cartesian product to select from, rather than selecting language and country? If this were a combo-fix with your typed string being a search filter, then maybe not. Otherwise it quite tedious to do all the scrolling while half the text remains the same.


> and
> also I don't believe that people spend more time scrolling through the
> ~longish list now than they would do with two shorter lists;

Ah, but usually they will only need to scroll through one shorter, and easier-to-scroll-through, list!

>   * new class of user errors will appear, with people forget to set country
> where important;

1. I believe that already happens - because the place you need to remember to set the country is not the font dialog :-P
2. If people won't set the right country then, why should they set it now? They can choose a related country with the same language (or the first one). Do you think I bother setting the country for Arabic?

>   * new kind of complaints will appear from users whose attention gets
> attracted to the sudden change, who will start to ask why (why the change,
> and why the country matters here, when this didn't even cross their mind
> before).

That's more positive than negative, because:

1. They will become educated about the importance of locale for some features and
2. It's an opportunity to tell them about the _real_ problem (bugs 151290, 148257, 151215).

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