Skip to content
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

Closed
askvortsov1 opened this issue Mar 27, 2020 · 11 comments · Fixed by flarum/lang-english#175

Comments

@askvortsov1
Copy link
Sponsor Member

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

@franzliedke
Copy link
Contributor

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:

you don't need to open 2 PRs every time you add a new setting to extension, and you can release extensions and language pack independently

But, also, to quote myself from the other discussion:

There was lots of discussion about this when we made that decision. I don't remember the reasoning, but I do remember it was a very deliberate decision, weighing trade-offs and all that.

Could somebody do me the favor and try to dig up that old discussion? It must have been with participation by @dcsjapan and @tobyzerner (then @tobscure). This should help us reach a conclusion here.

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.

@tankerkiller125
Copy link
Contributor

@franzliedke I read every discussion that @dcsjapan participated in that I could find here on flarum but was unable to find a discussion on this subject.

@askvortsov1
Copy link
Sponsor Member Author

I've also gone through, and have been unable to find relevant conversations. Are there plans to reach out to either of these people?

@rob006
Copy link
Contributor

rob006 commented Oct 24, 2020

PR: flarum/lang-english#175

@SychO9
Copy link
Member

SychO9 commented Oct 24, 2020

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.

@askvortsov1
Copy link
Sponsor Member Author

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.

@rob006
Copy link
Contributor

rob006 commented Oct 25, 2020

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

@qiaeru
Copy link
Contributor

qiaeru commented Feb 18, 2021

Sorry to answer so late, I missed this PR.

Personally, as a language pack maintainer, I think it will add a lot of work:

  • Before the merge, I could simply track the changes done by reading the commits made on a single repository.
  • Now, I'll have to go frequently to about ten repositories to see if any changes have been done.
  • I will also have to go to Flarum's profile on GitHub to check if a new bundled extension has been added.

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

@askvortsov1
Copy link
Sponsor Member Author

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.

@rob006
Copy link
Contributor

rob006 commented Feb 18, 2021

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.

@qiaeru
Copy link
Contributor

qiaeru commented Feb 19, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants