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

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

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.

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 🙂

Pherinos

Merci beaucoup !

clarkwinkelmann

Pherinos please use English only outside of Language Pack extension discussions as per our guidelines 😉

Pherinos

clarkwinkelmann
Sorry, mistake, it was an answer for an another thread for frenchies ;-)

« Previous Page