Extensions translation : In their own repository or in Language pack?

Hiob

Hello everyone !

Recently, I decided to translate in french the most used extensions on Flarum, flagrow.io.

By going around the extension repositories and the different language packs and especially the French one, I thought understand the tendency to integrate the various translations directly into the extensions' repositories.

But after talking with @MichaelBelgium (here) and @Ralkage (here) on my PR, they invite me to do my PR on the language pack, which I did. Others seem to prefer that it be done on their own repositories and merged my PR.

Is there a better way to proceed? In the extension repositories, in the language packs or is it left to the preference of the developers?

thanks!

Coucou @clarkwinkelmann @Qiaeru ! 🙂

luceos

Hiob this has been a discussion between several prominent extension developers for a while. The verdict eventually seems to move towards language packs carrying the responsibility. The primary reason is that extension developers aren't able to review all languages. Language pack maintainers are for their language individually.

Hiob

luceos Yeah, I agree with that, it’s make sense. Seems more easier for developpers and translators to maintain their repo, separately.

MichaelBelgium

luceos The primary reason is that extension developers aren't able to review all languages

This. Just no knowledge of foreign languages.
For example, in my extension flarum-profiles, someone did a PR for polish language and I don't know any polish (or french (ok a bit, but you get the point)) and it's not up-to-date anymore (it's missing a translation key because well, i don't know the translation), so I can't really flawlessy translate every translation key. The maintainers of language packs know better than me,

Qiaeru Flarum language pack's files will be unnecessarily large for those who don't use any extensions which are not the default built-in extensions.

It's already large. You got all those core translation keys + all the official extensions. A few more keys won't hurt.

Qiaeru The maintainer of a Flarum language pack can not guarantee that these translations are up-to-date (there are too many third-party extensions, so it's a large workload).

Neither the extension maintainer (even less than the language pack maintainer) - like i said above.

It just doesn't fit in an extension, while you have language packs. Language packs contain translations. Extensions shouldn't (only the english translation)

Even better:
By saying it should be in the extension, then why didn't you do pull requests to the official extensions with those translation keys in stead of making the french translation pack?

Qiaeru

I'm not sure about this solution, I see two main issues so far:

The maintainer of a Flarum language pack can not guarantee that these translations are up-to-date (there are too many third-party extensions, so it's a large workload).
Flarum language pack's files will be unnecessarily large for those who don't use any extensions which are not the default built-in extensions.

For these reasons, the French language pack for Flarum will not contain translations of extensions (except for the official ones which are included by default in the software).

I think the best solution is that the translator of an extension releases its translation through an extension, like a Flarum language pack. 🙂

luceos

Qiaeru both of your arguments also apply to the extension maintainer. 😉

Qiaeru

luceos Yep, I agree with that, that's why the translator should release his work through an extension. 😃

Ralkage

Qiaeru it technically already is 😉 if you take a look at any current language packs for beta 8, they extend the LanguagePack extender and having the name “extend” alone would clearly tell you what it’s doing.

In the defense to why we came about the conclusion to not support direct translations within a extension is purely straightforward. What if we wanted to add, remove, or edit current English strings within our own extensions? We’d run into a problem because we would either have to wait for someone who speaks the native tongue of other translations that were provided or just release an update as-is which wouldn’t be very professional and would hurt the extension ecosystem in many ways. Most of the PR’s I came across within ReFlar and FoF were purely translation files and we weren’t really sure if the translations were accurately or not. There is no clear way to determine that factor unless we either ask for a second eye to look over it who knows that language or use translation software which is not really 100% accurate.

Again, I’m truly sorry that this may have caused you some inconvenience but I do hope you understand the exact reasons I provided to why we went down this route 🤗

rob006

MichaelBelgium The maintainers of language packs know better than me,

But they don't necessary want to (or even able to) track hundreds of extensions for any change in translation and release every day to keep up with every popular extensions in ecosystem. From scalability and UX perspective it is better to keep translations in extension itself, because it always will be less languages than extensions, so it will be easier to maintain languages list in extension package than manage extensions list in language package. Especially from Composer constraints perspective - it is just impossible to maintain correct constraints for such translations package.

Qiaeru

I'm not saying that extension's translations should be added in the extension (I understand the point of view of extension developers), but I said that extension's translations should be released as extensions.

Plus, you're saying that it's only few extra lines to manage, but it will be "few extra lines" with each extensions, that's just HUGE (imagine if there are 100+ extension's translations). As a language pack maintainer, I can tell you that I don't have the time to maintain (or review) this.

Hiob

Hey,

after an exchange with @Qiaeru and checking around some similars projects, I setting up a repositories/package under an Github's organisation for the (french) third-party extensions translations, to have two differents repo; one for Flarum's bundled extnesions and one for third-party ones. It's a work in progress.
I think it's a good alternative to solve the problem and simplify the maintenance.

https://github.com/rooaaar
https://github.com/rooaaar/lang-french-extended
https://packagist.org/packages/rooaaar/lang-french-extended

Be free to let me known how to improve it. 🙂

I will post it in Extensions > Languages tag when everything will be ok. 😃

@MichaelBelgium you can remove my translation from your extensions. 😉
(Oh! And there is an error, flarum installation didn't work when we enable profile-views since my contribution. I will open an issue on Github., if necessary)

luceos

Hiob I think this is a great idea, thank you for your thoughtfulness!

MichaelBelgium

Hiob Oh, why wouldn't it work with another translation? 🤔 But alright, will look at ur PR. Nice alternative with the extra repo!

Edit: i've added translation packs in my "suggest" block of composer.json in profile-views and discussion-views which contain a translation for them. Thought it might be useful

luceos

MichaelBelgium Edit: i've added translation packs in my "suggest" block of composer.json in profile-views and discussion-views which contain a translation for them. Thought it might be useful

I talked on discord about this

@MichaelBelgium i understand, but I'm not sure it's wise. You can't be sure those extensions actually contain up-to-date translations. In addition you pull back the responsibility of keeping a list of valid extensions which are translated. But i like your proposition.

Instead what if we introduce a new key in the composer.json for language packs that allow them to provide information on what extensions they provide translations for, including their version; eg:

"extra": {
    "translates": {
        "flagrow/upload": "0.4.*"
     }
}

This information could then be parsed and displayed on flagrow.io.

rob006

rob006 But they don't necessary want to (or even able to) track hundreds of extensions for any change in translation and release every day to keep up with every popular extensions in ecosystem.

This is mostly solved by an initiative from this thread - fetching new translations is automated and translating using Weblate should be much more convenient and efficient.

There are still some scalability issues with this approach:

Right now Flarum loads all translations from language pack. Big translations packs may slow down forum by loading hundreds on translation files for unused extensions. There is an issue about that on GitHub, hopefully it will be fixed in core.
Even if above issue will be fixed and unused files will not be loaded, these files will still exist and language packs may be considered heavy (at least from cheap hosting perspective with low inodes limit). But keeping translations in extensions does not help much here - 30 extensions with translations for 10 languages will generate 300 files - same as one language pack with translations for 300 extensions. Both approaches will create a lot of unused files.

peopleinside

Hi to all, I feel confused and deluded, also curious to understand a little bit more the future of the extensions Friend of Flarum.

All this extensions will not support anymore other different languages from English?
So if a community is on a different language what to do? Some parts of this community should stay in English?

Today i created an Italian translation for links extension FriendsOfFlarum/links12 and discovered this will be no more supported. How should i feel?

How actually an extension can be translated is very easy to anyone so maybe will be users interested in having his own language that can add, update the file. I think is not a good idea remove the languages support or change to be impossible maybe for user as me to understand on how auto-fix.

In the future how to translate the Friends of Flarum extensions? Will be no more possible?

matteocontrini

peopleinside translation support wasn't removed. Translations should be put in language packs

Pollux

peopleinside

Language files belong to a language and to an extension. They can reside within a language pack or within an extension, both works fine. When I learned about flarum for the first time both ways were used. Extensions came with a couple of supported languages and language packs supported a couple of extensions. At one point that became inefficiant and confusing.

In the end it's a question of responsibility. Should it be the responsibility of the author of an extension to provide translations for all the languages or should the author of a language pack (technically an extension as well) provide translations for all of the extensions?

Both is not 100% feasable (in the real world there will always be some obscure extensions without a translation to a lesser used language). But it seems much easier for a native speaker of any language to translate the terms used in most extensions than for an extension author to collect translations from different sources to offer a "complete" set of languages.

That's why nowadays extensions usually come with a language file for English only.

peopleinside

Pollux Sure maybe now is more clear. I hope only... in the extension will find instruction to how user like me not experienced not translator etc... can create easly as is now a file that fix issues.

Maybe will be ok if just need create the same file but put on a different place 🙂