Locale bringup and barriers for entry

Wed Sep 26 09:43:22 CDT 2018

CLDR does not currently handle octal or hexadecimal formats because those
are not in customary use by normal users. They are clearly used by
programmers, but that is specialized usage that doesn't require special
formatting across human languages.

I suggest that people focus on practical issues connected with CLDR and not
ramble on about issues that are not particular important to CLDR users.

Mark

On Wed, Sep 26, 2018 at 5:00 AM Marcel Schneider via CLDR-Users <
cldr-users at unicode.org> wrote:

> 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 <
> 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
>> >
>
>
>
>
> _______________________________________________
> 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/766465b5/attachment-0001.html>