-
-
Notifications
You must be signed in to change notification settings - Fork 826
-
-
Notifications
You must be signed in to change notification settings - Fork 826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundled extensions should use the locale extender instead of the lang-english language pack #2090
Comments
To continue discussion from #2020... Right now, I lean toward moving English extensions to the bundled extensions as well. @rob006 made two points that are important to me personally:
But, also, to quote myself from the other discussion:
I know these two people put a lot of effort and thinking into making this decision, so I would love to read up on what made us adopt the current approach back then. |
@franzliedke I read every discussion that |
I've also gone through, and have been unable to find relevant conversations. Are there plans to reach out to either of these people? |
It could have been that the decision to include all text strings in one extension as a language pack, was for the sake of making translation and creation of other language packs easier to the community. |
I still lean in favor of moving translations for individual extensions to their codebase. This has become the standard for extensions across the ecosystem, and we might as well follow it with bundled extensions. But I would prefer for core to remain language-agnostic. It's just that the english lang pack would only contain core and shared translations, and other language packs would contain translations for core and all needed extensions. I would also like to look into tools for making language pack creation and maintenance easier. Promotion of your awesome weblate tool could be a great step towards that. |
@SychO9 I'm a language pack maintainer and I don't see how this language pack could make my life easier. It is actually the opposite - if I want to automate fetching original translations from extensions, I need special rule for official extensions. @askvortsov1 Core is not language-agnostic. It sets English as fallback language and it contains English translations for dayjs. Core already prefers English, lack of English locale in core just make it incomplete and inconsistent, since core will work differently than everything else. Also, all disadvantages of current design (you need 2 PRs for new feature, English fallback for missing translations may not work) affect core in the same way as extensions. In case of core it is even more significant, since most of translations is for core and most of development also affects core, so you will gain more by including locale in core than doing this for extensions. |
Sorry to answer so late, I missed this PR. Personally, as a language pack maintainer, I think it will add a lot of work:
Clearly, this is going to put a lot of work on the translators (I don't know if I would have time in the future to release my language pack at the same time as a new version of Flarum). 😟 |
In the long term, we hope and expect to see the number of extensions and language packs rise dramatically. This makes managing translations for them very difficult (as you noted, if keeping track of core changes is so complex, doing so for community extensions is much, much moreso since there isn't a centralized place for them). It also becomes much more difficult for one person to manage translations for an entire language. At least personally, I believe that better tooling, testing, and ecosystem tools are one of the most important things we can do for Flarum. I am extremely excited to see all the work that Rob has generously put into https://discuss.flarum.org/d/20807-simplify-translation-process-with-weblate/20. I believe that Weblate is the future for Flarum translations: it's all in one place, managed with a nice UI, and pulls in new updates for extensions automatically. Much more scalable and easy to manage than having to manually look for changes, compare them, and update a repo. Over the past few years, the community has shown a clear and overwhelming trend towards having english translations in each extension's repo, and translations in other languages in the appropriate language packs. This change updates bundled extensions to reflect that, and more importantly, avoids having this edge case: now, all extensions (and core) structure their translations similarly, which should make it simpler to automate managing them. There are other benefits, including an easier development process (no more forgetting translations with core/bundled changes) and much less issues with translations not loading at all, but the above is the main reason for this decision. |
If there is such desire, I could prepare repository with all original translations files, similar to https://github.com/extiverse/premium-translations but for all extensions. I'm already tracking all releases, so downloading all translation files to one repository should not be hard. But it still looks like way more work for language pack maintainers than switching to Weblate. Not to mention that it also harder for community to contribute to language pack. |
Thanks for your replies! Indeed, Weblate seems to solve the issue, do I don't think it's necessary to prepare a new repository with all original translation files. I'll look into it, you should see a new request for the French translation in a near future. 👍 |
This convention is already followed in all other extensions, I don't see why bundled extensions should be treated differently. This will make them more modular, easier to maintain, and easier to transition extensions between bundled and non-bundled.
See more discussion in #2020
The text was updated successfully, but these errors were encountered: