Op 10-06-2021 om 18:17 schreef Richard Narron:
If we use UTF-8 for names in Spanish, where does it end?
I cannot easily recognize UTF-8 names in Chinese or Thai or Russian or
Japanese.
SBo could require that Japanese names can be required to be
transliterated into Romaji form
<https://en.wikipedia.org/wiki/Romanization_of_Japanese>. However real
Japanese names are written in kanji. The problem here is that while
different kanji may be pronounced the same (and therefore they can also
map onto the same romaji-string) while in the Japanese script, these
different symbols refer to different persons.
Therefore, if you only have the romaji representation while you don't
have the name as it is written in the Japanese script, you'll have a
hard time tracking down the person and or verifying that you have found
that particular person if the need should arise.
So you should just use the Japanese or Chinese representation for the names.
Please note that Chinese also has the exact same problems. (the
terminology for "kanji and romaji" is "hanzi and pinyin" for Chinese, so
the Chinese languages behave the same in this regard)
A fix might be to request that Chinese and Japanese people include both
a transliterated name and a name in their native script.
But for matters of accountability or the acknowledgement of merit, there
is no way around writing the names in their native script.
Therefore, I don't see any other appropriate solution than using UTF-8.
My keyboard does not easily support such languages.
If you run "chmod +x /etc/profile.d/scim.*sh" and do some configuration
your keyboard does support Japanese and Chinese characters. I use SCIM
on Slackware 14.2 on a regular basis.
If we allow UTF-8 names in SlackBuild scripts then how about UTF-8 in
documentation and descriptions?
Where does it end?
I hope that it's clear that this issue should have been resolved years
ago and that there's really no way around UTF8 anymore. It should just
be implemented and used by default. Slackware 15 apparently uses it by
default so that's the direction in which things are moving. We should be
thinking about how we are going to support UTF8 as well, because UTF8 is
going to be the default that will be used everywhere whether we like it
or not.
However, I am also aware that quite a lot of software is still incapable
of processing UTF-8 properly and that this might cause problems in the
actual .SlackBuild scripts and documentation-files at the time of writing.
So as a compromise I propose that we use UTF8 for the .info files, but
allow the use of ASCII in the scripts for now.
If we combine this with a kanji and a transliterated version of the
names written in Japanese, Chinese, etc. we can properly allocate merit
and accountability without having to worry about this right now.
Note that this solution is not a permanent one.
Its main benefit would be that it provides us with a proper amount of
time to come up with something better.
I would hope that we keep the English language as a standard for
software that I can, read and write and that matches my keyboard.
I understand your desire for "Keep It Simple Stupid", but I just don't
see a way around UTF8 anymore if SBo, Slackware and Linux in general,
want to stay relevant for the next 10 years. This map
<https://brilliantmaps.com/population-circle/> really drives the home
the point about the enormous number (billions) of people in Asia and
those aren't the only people which use a writing system that cannot be
expressed adequately through ASCII, because these problems also apply to
Dutch (my native language), French, German, Polish, Swedish, Norwegian,
Italian and many more.
If we are not going to support them, we're going to get marginalized and
replaced in less than a decade by something which does support their
native languages.
Spycrowsoft
_______________________________________________
SlackBuilds-users mailing list
[email protected]
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
