Skip to content
Robert Korulczyk edited this page Aug 21, 2020 · 14 revisions

How does it work?

This repository contains configuration and raw translations data. Translation data is fetched by Weblate instance and displayed in a nice and convenient GUI. All translations made by Weblate are then exported back to the repository, so all translations are always kept publicly in this repository.

In addition, there is a simple script which automates some tasks:

  1. Fetches new translation strings from extensions - this automatically detects new strings for translate and changes of existing translations.
  2. Exports data from this repository to language pack extensions. In this way translations made by Weblate may be exported to any extension and be installed and used in Flarum. Polish language pack may be an example.

How long does it take for the text translated in Weblate to appear in the language pack?

It is two-step process:

  1. First Weblate needs to commit translations to main repository. In order to reduce number of commits, Weblate delays actual commit for about an hour. If you're language pack maintainer, you can force commit immediately using Manage -> Commit option in component summary (screen).
  2. In second step translations are exported from main repository to particular language pack. This is handled by cron job run every 10 minutes. So at worst case it can take up to 10 minutes to update language pack after Weblate commits changes to main repository.

TL;DR: It should take no more than 70 minutes, but as a language pack maintainer you can easily reduce this time to less than 10 minutes.

Note that this will export translations to branch, so composer update me/my-language-pack may not install these latest changes (by default Composer installs only stable releases from tags). You may need use something like composer requite me/my-language-pack:dev-master in order to force installing version from branch, or create a tag (you can only do this as a owner of language pack repository).

How to add missing language/extension?

Currently there are no detailed instructions for that. If you want to maintain language pack using collective, or you noticed that some extension is missing, please open a new issue or ask on Forum.

I'm a language pack maintainer - why should I bother this project?

  1. Because it is easier to translate using Weblate GUI than editing YAML directly. You will have easy access to source string, and some additional information, like similar translations in other places (screen). Zend mode will allow for fast translation without unnecessary distractions (screen).
  2. Weblate has automatic checks that detect basic inconsistencies between source and translation (screen).
  3. Weblate features: comments, screens, suggestions, voting, summaries, advanced searching, and many more.
  4. Engage the community - translating using Weblate GUI is much easier than editing file via GitHub. Some issues or missing translations can be fixed directly by users - less work for you ;).
  5. No need to monitor extensions for new strings or translations changes. New strings for translation will be automatically detected and you will get an email notification about new things to translate. If the original string was changed, it will be marked as "Needs editing" with change diff, which should help you adjust your translation (screen). Even less work four you! :)
  6. Badges for indicating the status of translation (screen).
  7. Helper command for generating releases for language pack. It generates changelog entry, publishes release (following semver) on GitHub and generates an announcement for forum discussion. See example for Polish language pack: template, changelog, release, and discussion on the forum.
  8. Simple summary with list of extensions ordered by number of monthly installs - it should help to decide which extensions are the most popular and should be translated first (example for Polish).

If you have any additional questions, please open a new issue or ask on Forum.

Clone this wiki locally