Locale bringup and barriers for entry

Tue Sep 25 21:59:40 CDT 2018

What locales are you referring to? If they are new to CLDR, and you experienced difficulties in setting up their numbering system, then there is yet a supplemental barrier.

As far as I can see, I only know Sumerian and Babylonian locales using sexagesimal numbering. Octal and hexadecimal/tonal as a locale’s numbering system are discouraged as counterintuitive, as they neither allow people to count on fingers in a straightforward way, nor to efficiently communicate digits using hand gestures. More generally, I don’t believe that it could be useful for a locale to focus on its numbering system in order to get away from widespread usage. Yes we really do need to make changes, but the numbering system does in no way appear to me to seem to be in any way the right end to begin with. Sorry to tell it bluntly, but I’d suggest to focus on getting all existing locales into CLDR, unlike what is suggested in the comments I’d pointed in my previous message, and on fixing existing errors. If any existing living locale does use octal, tonal, sexagesimal, or whatever non-decimal system beside purely notational conventions like Roman, then indeed we need to dig deeper into the matter in order to get them into CLDR.

Having said that, as Steven pointed out, there are already some locales using algorithmic numbering, as seen in the data:

https://www.unicode.org/repos/cldr/tags/latest/common/bcp47/number.xml
https://www.unicode.org/repos/cldr/tags/latest/common/supplemental/numberingSystems.xml

For reference, here is the specification, not very explicit about algorithmic:
http://www.unicode.org/reports/tr35/#Numbering%20System%20Data

Nevertheless I don’t think that Nystrom was wrong in challenging the elites of his generation, given the current approach proved to be a slope into catastrophe, so that today we need to make changes at 180°, or 8 tims when expressing it in tonal, like those suggested on:
http://sunsite.monsite-orange.fr/page-5b9e092880342.html

Regards,

Marcel

On 26/09/18 00:43 Philippe Verdy via CLDR-Users wrote:
>
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  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  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
>

_______________________________________________
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/ffe868f6/attachment.html>