How to organize the maintenance of localizations

[lizmat]

So far, we have 6 localizations in the core (DE FR IT HU NL PT). We could possibly have many more in the future.

It has been mentioned that we should maybe put these in the ecosystem.

With rakudo/rakudo@d62f7780f2 I have moved all the localization module update logic into the RakuAST::L10N, making it a lot easier for an author to create their own localization and have them installed / activated by zef, just like any other distribution.

As a proof of concept, I have made a L10N::TLH localization (aka Klingon).

It is now feasible to move all of the current "core" localizations into the ecosystem. This also has the advantage of them being updatable apart from any Raku releases.

My question is really: should I upload the localizations under my own :auth, or should we maybe create a group (both on Github, as well as on fez) to be the authority?

[vrurg]

Can it be raku-community-modules?

[lizmat]

It could be. But that feels a it too free for all. As I do think the localizations are an extension of the core, and thus may need to be aligned, although also separated.

[coke]

I think a separate project makes sense, not raku-community, but perhaps a new raku-core

[lizmat]

It should also be noted that these localizations would effectively be like language versions to the users, so any changes would have to be looked at very seriously.

In that light, I've made it possible to be more specific in the localization argument to .AST and .DEPARSE: they can now also :auth, :version and/or :api information. For instance, .DEPARSE("TLH:auth<zef:lizmat>") would use the most recent version of my localization of Klingon.

[finanalyst]

@lizmat would it be possible to indicate what core localizations means, and what module localizations might mean.

Are we talking only about non-English versions of Raku? (I think that's what's meant, but I wanted to check).

If we only discuss non-English versions of Raku:

• I think that the term L10N is a bit too general. It seems to indicate that any set of language mappings could be used in standard Raku. For example, say is standard Raku, perhaps skazhi in a Slavic-type version (I'm avoiding Cyrillics for this post), or dweuda in Welsh. But dweuda is not admissible in standard Raku, only the localised version of Raku.
• To avoid L10N, I said non-English Raku, but this is also too clunky. Maybe Raku-dialect?
• Alternatively, we could stipulate now that L10N has a more restricted meaning for Raku as a language.
• It seems to me that perhaps there should be an :auth group for each recognised non-English Raku. For example, changes to a Chinese version should not be possible for someone who may understand the consequences for Welsh, but not simplified Chinese.

[lizmat]

would it be possible to indicate what core localizations means, and what module localizations might mean.

A localization is a pair of modules, one for parsing (L10N::FOO) and one for deparsing (RakuAST::Deparse::L10N::FOO). If these are part of the core (living in lib), I call them "core localization". If such a pair of modules live in the ecosystem, I called them a "module localization". The latter name may indeed be confusing. Suggestions welcome!

I think that the term L10N is a bit too general

Perhaps it is. But I find "dialect" also a bit confusing, as some people assume Raku is a dialect of Perl.

It seems to me that perhaps there should be an :auth group for each recognised non-English Raku.

Perhaps. But I'm going to assume that the group of translators with commit bits, will be small to begin with. So it feels a bit like over-extending at this point.

[lizmat]

My proposal would be to create a "raku/L10N" repository, and a "L10N" group in fez.