RE: Re: Is there any desire to support languages other than English in zsh?

[zeurkous@xxxxxxxxxxxxxxx]

On Thu, 08 Jun 2023 12:13:41 +0200, Oliver Kiddle <opk@xxxxxxx> wrote:
> Agron Selimaj wrote:
>> What if we take the long path by starting small?
>>
>> Let me add gettext support, and we don't have to use it everywhere from day
>> one.
>
> This seems like a sensible approach to me. Adding gettext(), is mostly
> just about identifying information messages so doesn't need extensive
> knowledge of the existing internals. A --disable-nls configure option
> can be added to satisfy anyone who is concerned about the implied bloat.

The bloat is also on the source level. This can make maintaining code
{,significantly }harder.

> There may be border-line cases such as the prompts for history searching
> ("bck-i-search:") where we may want configurability at a zsh associative
> array level like Peter was suggesting. But that can perhaps come later.

Given the already relatively self-contained nature of zsh, me'd argue
for the associative array approach, zeroth.

>> This means, I'll make this text be extractable to generate *.POT files and then
>> we can use all kinds of tools and websites to do the actual translation.
>
> I'm vaguely aware that websites exist to allow non-technical people to
> contribute translations. Do you know of any good ones? It would be best
> if we have an individual or small team that keep that in step with the
> git sources going forward so that people interested in the C internals
> need not be too concerned with the translations.

Dear $DEITY, please let's not let people contribute translations
unchecked at all, and on top of that, "non-technical" people tend to get
"technical" things wrong.

Very wrong. Misleading and incorrect translations will be a fact of
life.

>>     This is definitely not something we would want to dive into until
>>     after whatever the next zsh release is, is done.
>
> I don't think its especially helpful to put off any particular efforts
> on that basis. If the release manager feels that some recent work is
> half-baked, git makes it very easy to create a release branch off from
> some earlier point and backout or cherry-pick changes. Or something new
> can be diverted into a temporary feature branch. Currently, I'm not
> aware of any vague plans around timing for whatever the next release
> will be but that would be a separate discussion.

While seeming simple initially, these kind of changes have the potential
to become quite invasive. Perhaps deferring any such work is best, but
a feature branch could work.

> | An incomplete, underdesigned "feature" upsets people more than a lack of
> | such, IME. Besides, sprinkling gettext calls around just leads to more
> | bloat, and more importantly, is inconsistent with the existing design
>
> I don't see that as leaving the feature "underdesigned". It'd be fully
> designed,

That sounds like a pipe dream for now. Working w/ natlangs is
notoriously difficult, even for native speakers (most of them haven't
quite mastered their mother tongue{,s}, either). Giving the amount of
messages in zsh, we'll be finding grammar problems forever. And me'll
hazard the prediction that some of them just cannot be fixed without
compromising the exact meaning (mehopes medoesn't have to elaborate on
how very important exact meanings are in computing).

> it is just the coverage of strings that may be incomplete
> ("from day one"). Our coverage of the world's many languages can never be
> complete.

Yes. And that leads to no end of work, while we're already struggling to
manage the many features we have (and especially their interactions). 

We'd be inducing expectations that we cannot hope to ever fulfill.

> It'd probably be best to have decent coverage of strings and
> at least a few common languages covered before it makes it to a release.
> gettext() calls can be substituted by a macro that does essentially
> nothing so no bloat is forced on binary builds.

A macro hides bloat; it does not remove it.

        --zeurkous.

-- 
Friggin' Machines!