On 7/30/19 3:57 PM, keld_at_[hidden] wrote:
> On Tue, Jul 30, 2019 at 11:12:53AM -0400, Tom Honermann wrote:
>> On 7/30/19 10:14 AM, keld_at_[hidden] 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