The Flarum Language Project

Kakifrucht

rob006 It would certainly also make sense to offer this functionality in core. Meanwhile I have fixed the cache clearing after changing setting and believe my solution is pretty good.

vaultboy

bigreja Qual é o fórum? Em relação à tradução, já está completa ou não, posso ajudar se for preciso.

GreXXL

vaultboy this is an English speaking community. Please post in English only, as pointed out in our guidelines.

Kakifrucht

rob006 until we have a more final solution on how to integrate it, is there anything stopping me from merging my formal implementation for now? it wouldn't touch the locale folder, so I don't think Weblate would care.

rob006

Kakifrucht I prefer to wait, as final solution will have different convention for settings name, so having temporary solution will require creating migration in the future. I also have plans to finish this on weekend, and I don't think that 3 days of delay will make a huge difference.

rob006

Proposed extender: https://github.com/flarum-lang/utils/blob/master/src/Extend/LanguagePackWithVariants.php

@Kakifrucht Preview for German language (this is only a preview, these changes will be replicated again on target repository): https://github.com/rob006/flarum-lang-german/tree/formal

Formal variant is also available on Weblate (it is not exported to language pack right now, but I enable this tomorrow or on Monday): https://weblate.rob006.net/languages/de@formal/flarum/

@Darkle You may also want to take a look at this, if you want to integrate the same solution for Spanish language pack.

Kakifrucht

rob006 I like the interface here allowing language maintainers to easily add language settings to their translation packs, but is the repository duplication really necessary? It causes various problems, such as desyncs between the packs, having to update them both with every change and forcing the language maintainers to manually fix them up when someone only inputs their translations to one of the two variants (probably the one they care about).
This seems especially unnecessary, when all that changes with a variant is maybe 15% off all strings. It would be alot better to just direct them at the complete pack and add a note to the contributing readme section that they may also want to provide a formal variant link to weblate if necessary.

Edit: seems like I misunderstood and Weblate handles the situation correctly here. Do I understand correctly that the export happening into the formal directory merges the strings set in de@formal with the ones in de? In that case ignore my comment above.

Darkle

rob006 I'll try to look at it next week and see what I need to do, if you need to do something on your side you can go ahead, I have discussed it with jslirola and we are very much in favour of a joint solution.

Oshvam Gracias por avisar, se me había cerrado la sesión y pensaba que estaba todo bien, ya está arreglado 🙂

rob006

Kakifrucht Yes, all missing translations for formal variant are taken from informal translations, so there is no need to translate everything twice - you can focus on informal translations and bot will handle duplication in language pack repository.

The only real downside of this is that Weblate will treat these skipped translations as missing, and all status badges will show that extensions are mostly untranslated, even if translations are actually complete and no action is required. I have no idea how to improve this - the best way to signalize that no action is required for specific phrase, is to translate it.
Hiding status badges for formal translations in readme is also an option, but I'm afraid that it will be to hard for users to find how to contribute translations if they're using formal variant.

Kakifrucht

rob006 That seems like an ok tradeoff to me. I didn't plan to put those badges in the readme in the first place and I would edit the contributing section to explain that formal translations need to go towards the formal repository, however only if formal and informal differ. People would still mainly get directed to the non formal Weblate repository.

Feel free to merge it into the master branch when you are ready.

Edit: The bigger problem I see here is that it seems not possible to translate for both repositories in one view. That would be optimal, to get both of them into the UI. Only thing that can be done right now is to show the formal translation if it exists already.

naxvog

Wouldn't it be much easier if there was a core supported concept to define a fallback?

I locally achieved this by introducing a "fallback" key in the extra section of the translations composer.json to register one or multiple fallbacks (default: en).
Using this approach you just need to add the default language variant as a required package and you are golden.

Symfony already supports language fallbacks btw

PS: Would love to post a PR to GitHub but I am currently unable to do so until my ISP stops screwing me.

Kakifrucht

naxvog I'm not sure I understand the advantage with this approach. From a UX perspective, wouldn't it be more senseful to only require the installation of one language pack which then allows toggling between variants from within the admin cp?
Additionally, if I wanted the formal variant I would have to install two language packs to get there.

naxvog

Kakifrucht
I would like to avoid additional logic in a translation extension.
Additionally the formal variant can be much more lean as all informal translations are handled by the informal fallback. Also I am still trying to avoid duplicate data handling.

rob006

@Kakifrucht It is all set up now. I manually tagged 1.5.0 release, as this transition was too confusing for bot and automated PR was useless, I hope it is fine.

Kakifrucht

rob006 great, thank you! One issue I have found is that changing the variant requires a manual cache clear. It would probably be better if that was automated.

rob006

Kakifrucht I'll take a look at this - I probably tested this with debug mode enabled, which always revalidates cache... 🤦

rob006

Kakifrucht I released new version which should fix this bug. You can install it using composer update or composer update flarum-lang/utils.

Kakifrucht

naxvog Have you looked at rob's implementation? Besides the definition of which variants exist, which you would do in the extension itself there is no additional logic in the language pack itself, it is imported through a composer package. The formal language repository on Weblate does not contain duplicates, only the strings that change.

Oshvam

Darkle hola Darkle, disculpa que te contacte por aquí, no tengo otra vía. La comunidad en español está KO

rob006

Darkle You don't need to do anything, I'll add formal language to Weblate and adjust language pack repository (I need to sync this with changes in bot configuration) next week. Just be aware that I may need to tag new release of language pack at any point.

Darkle

rob006 Ok, I'll keep an eye on it, as for the flarum-lang/utils, I should add it to composer.json - extend.php and remove the current implementation we use for the language register selector, right?

« Previous Page Next Page »