Le 2019-06-19 12:48, Jens-Ulrik Petersen a écrit :
Hi
And yes as Nicolas also said maybe we need: langpacks-ko-fonts and
langpacks-ko-input-methods, etc.
I's much more than input methods, it's anything you need to read/write a
language (input, spell/grammar, fonts, etc)
Though the whole concept is difficult to convey in metapackage naming to
non-technical users. After thinking about it some more, what would be
understandable for everyone involved is
langpack-ui-foo Recommends langpack-foo
and
app-langpack-ui-foo Recommends app-langpack-foo
app-langpack-ui-foo Supplements (langpack-ui-foo if app)
app-langpack-foo Supplements (langpack-foo if app)
since UI is better known than obscure acronyms like i18n or l10n
Now UNIX UIs have historically been horrible about all this, with *nix
devs deriving UI language from input layout and completely massing up
things. Microsoft is much better at it because Office is a major earner
for them, and it is used to create documents in many human languages, so
they had to learn how to do it properly a long time ago (last
millennium, circa ’95)
The DEs and Wayland really need to break the UI language/input tie-up
once and for all.
A user can consider that the localization of its favorite apps sucks
loads, and configure his system UI to use another language. That does
not mean he can switch the language processing capabilities of his
system to this other language, unless he can convince all the people he
interacts with in his country to switch too. So that's one major case
where UI settings differ from language processing settings.
Conversely, a developer will produce material using computer languages,
which are English-oriented, so he will often keep the UI in his native
human language, but switch the language processing to English. So, the
reverse difference exists.
Furthermore, anyone who speaks more than a single human language, will
want the language processing parts for all those languages. But the UI
can be all languages at once, so he'll only need a single UI langpack.
Lastly, DE settings (not necessarily the metapackages themselves) need
to separate cleanly input method from language processing. No one who
writes several languages that share the same script (for example
English/French/Italian…) will accept to switch from AZERTY to QWERTY to
QWERTZ whenever he switches languages. He will need to switch
spellchecking though.
So all the language UI = input method = language processing does not
exist in the real world and building technical solutions around this
false equivalence does not work
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
