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

[Oliver Kiddle <opk@xxxxxxx>]

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.

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.

> 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.

> On Wed, Jun 7, 2023 at 10:56 PM Bart Schaefer <[1]schaefer@xxxxxxxxxxxxxxxx>
> wrote:
>
>     Having previously overseen the gettext-ification of a piece of
>     software of similar original vintage and complexity, I would say that
>     supporting the databases is often the least of the issues.  Sentence
>     structure varies, which requires converting catenated substrings into
>     snprintf formats or sets of alternatives; pluralization may differ,
>     requiring 0 / 1 / >1 conditionals even with gettext intervention; etc.

Isn't that what ngettext() is for?
The domains - dgettext() - looks like something we might need to be
concerned with. Should modules use a different domain?

>     Also, because of the pervasive changes required, we found it necessary
>     to merge all outstanding code changes and call a halt to other
>     development until the "l10n" pass was complete, or we couldn't track
>     deltas accurately (though we were stuck with CVS for version control
>     at the time).

I can understand that having been necessary. It may matter less in zsh
if the pass is incomplete. And as software goes we probably have
relatively few user-readable strings (unless you count completion which
I assume is firmly out of scope for this).

>     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.

zeurkous@xxxxxxxxxxxxxxx wrote:
| > Let me add gettext support, and we don't have to use it everywhere from day
| > one.

| 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, 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. 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.

Oliver