Locale bringup and barriers for entry

Tue Sep 25 17:38:25 CDT 2018

octal and hexadecimal (as well as binary) are obviously numeric system
using the same digits (or borrowing additional letters or adding other
supplemental digits): the algorithm behind is the same as decimal, it's
just using a different base (not necessarily wrriten each time but infered
from the context), and that algorithm is equally simple, it's basic
arithmetic expressed over a cyclic group. That numeric notation is
contradicted by the way nbumbers are actually spelled in actual languages,
where the base is obviously not just decimal but is using larger bases
(most often 1000 in European traditions, but 100 or 10000 in parts of Asia,
with various exeptions using remainining traces of base 20). Historically,
numbers had mystic or religious traditions, and there remains some old
systems using base 12 (including the old English and Celtic traditions).

Octal and heaxdecimal are certainly modern inventions for technical reasons
(or limitations for and older state-of-the-art technology and costs of
implementations when pure binary system was simply unusable for most
usages; usage of octal is now deprecated, largely replaced by
hexadecimal... except in wellknown programming languages and in old
technical documentations for the oldest computing standards that were never
really deprecated completely to become really out of use or because of
compatibility issues: its support is still mandatory as its also impacts
how these programming languages are parsed into unbreakable lexical tokens:
it would be unpractical to change this basic tokenisation algorithm on
which the rest of the language is built, but a contrario, this is also
limiting the practical adoption of hexadecimal which requires more complex
syntax even if it should be more compact).

Still today, the decimal system is the most widely used, but may be in
solme future, hexadecimal will become popular and translated in actual
languages to express numbers. Then it will be time to have actual
characters added with distinctive forms for the 6 additional digits,
instead of borrowing Latin letters. This could come first from other
languages than those currently using Latin (I think it may appear first in
China, Japan or Korea, as part of the sinographic system or as extensions
of kanas and hangul, and rapidely adopted in South Asia, and once again
European scripts will be the last to accept the change, just as they were
very late in adopting the concept of zero, negative numbers and fractional
decimals using digits, and separators for grouping/decimals).

Yes, I don't see why there's still no hexadecimal extension digits added,
even if today most hexadecimal numbers are used only in technical
programming languages that are standardized only using basic Latin/ASCII.
The barrier is still the adoption also in humane languages for general use,
as well as various legal restrictions (notably for
pricing/billing/accounting/contracting/taxing). There's is less
restrictions in the old legal/judiciary traditions where other systems were
largely in use (and are still !)

Le mar. 25 sept. 2018 à 23:55, Steven R. Loomis via CLDR-Users <
cldr-users at unicode.org> a écrit :

> The numbering system is defined in TR 35 in
> https://unicode.org/reports/tr35/tr35-numbers.html#Numbering_Systems in
> terms of either '*numeric*' (which are decimal systems, just substituting
> different digits for "0123456789", such as “꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩”  for the Vai
> language, or else *algorithmic* which are more complex rule based. I
> suppose octal and tonal (hexadecimal?!) could be supported by the
> algorithmic approach.
>
>
>
>
>
> On Tue, Sep 25, 2018 at 2:27 PM Luke Dashjr <luke at dashjr.org> wrote:
>
>> It's been a while since I tried, but I didn't see any possible way to
>> define a
>> locale's number system (eg, octal or tonal instead of decimal).
>>
>> On Saturday 22 September 2018 00:34:27 Steven R. Loomis via CLDR-Users
>> wrote:
>> > Hello, and welcome to the new cldr-users members.
>> >
>> > For discussion:
>> >
>> > At the IUC conference last week, a few of us discussed around lunch some
>> > issues around getting new locales into CLDR, and barriers to entry.
>> >
>> > Barriers:
>> > - we discussed that it could be confusing or difficult to collect all of
>> > the data needed for a minimal locale:
>> > http://cldr.unicode.org/index/cldr-spec/minimaldata - especially
>> > pluralization data
>> > - what about fonts? keyboards?
>> > - what are the best ways to coordinate efforts between the language
>> users
>> > and different technical experts?
>> >
>> > Ideas:
>> > - a web app to take in new locale data?
>> > - a web app to debug/explore plurals?
>> > - allowing some locales to 'get started' without plural rules?
>> >
>> > Links for discussion:
>> > - Elnaz and Steven's prez from (last) Monday: https://goo.gl/sN7biw
>> > - My "full stack" blog post:
>> > https://srl295.github.io/2017/06/06/full-stack-enablement/
>>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20180926/f60a010c/attachment-0001.html>