[SG16-Unicode] Ideas for the future

Tom Honermann tom at honermann.net
Tue Jul 30 22:12:03 CEST 2019


On 7/30/19 3:57 PM, keld at keldix.com wrote:
> On Tue, Jul 30, 2019 at 11:12:53AM -0400, Tom Honermann wrote:
>> On 7/30/19 10:14 AM, keld at keldix.com wrote:
>>> The first thing - portablity - is what we have been aiming at for many years
>>> and involves a basic character set as we do it now. That is basically ASCII.
>>> No funny characters like · and ± and ÷.
>> I tend to agree.  I don't recall specific proposals for core language
>> features that would allow defining new operators, but I like that
>> approach as opposed to extending the basic source character set and
>> current fixed set of operators.  Keld, what would you think of that
>> approach?
> If I understand you corretly. we are talking of defining operators
> using characters outside the basic character set like · for maybe matrix multiplication.
> IMHO that would be fine but just some syntactic sugar for some function calling.
Exactly right.
>>> the second - cultural adaptability - is something about having all input and
>>> output in a fashion that users feel natural. We go a long way
>>> with the locale stuff we have, but I would like the language to support string to
>>> be marked as translatable, and an ecosystem to support it. Most serious programs
>>> today are written for translation. So some syntax for strings
>>> like g"translatable text" could be good. And then maybe some notion for voice too
>>> - and other possible outputs - eg for disabled people.
>> I agree that having a (defacto) standard way of specifying translatable
>> strings would be very helpful.  Is anyone aware of prior proposals or
>> widely adopted alternatives to POSIX/GNU gettext?  I have some
>> experience with Microsoft's resource DLLs for providing string
>> translations (and have implemented a similar system on non-Windows
>> platforms), but lack other experience. Anyone interested in working on this?
> I was thinking some syntactic sugar to call gettext like functions
> and then having an eco-system to support translators - has been working fine
> for many years. Do you want something that is different from gettext()?
> and why? I have been working with gettext for something like 20 years.

I don't have a lot of experience in this area, so I don't have strongly 
held opinions, nor a good understanding of what is considered good, 
modern, wide-spread practice.  My questions weren't intended to suggest 
that innovation is lacking or necessary.

Tom.

>
> Keld



More information about the Unicode mailing list