rob006
I've made several Portuguese translations, but i think the repo is not updated yet.
Can you check please?

      rob006 did it a couple of weeks ago, i will follow your link and translate what's missing.

          bigreja did it a couple of weeks ago

          Can you point any specific missing translation? There is a couple of unapproved suggestions - maybe you tried to translate as a guest? Only logged in users can translate directly, guests can only make a suggestions. And suggestions must be approved by someone before they will be exported to repository.

            Would it be possible to clone all entries for German into a new "German (formal)" language? Only some of the entries will need modifications to be more formal.

            Currently flarum might not be used by German speaking businesses internally mandating formal language for all their communication.

              naxvog in Spanish we have the same "problem" so we add both versions in the same translation. Using Weblate we translate the informal and then try to replicate the changes on Github for the other.

              https://github.com/flarum-lang/spanish

              As you can see, we have a selection box to choose which one we want to use in the forum.

              Talk to the person who is maintaining the language pack and maybe you can replicate our solution.

                  jslirola that might just be the best solution

                  Still to translate easily a new weblate language might be needed.

                  Is there the possibility to assign references to non formal translations so that we could avoid managing duplicate data?

                  @Kakifrucht Would you be interested in developing/maintaining such an extended German language extension allowing to choose between informal or formal language? Will try to make some time aiding in the development if you are interested.

                    @rob006 what is your opinion on the best approach for this? I am supporting for a formal version of German, even if a maintainer would be required at some point.

                      luceos I could add separate language to Weblate (for example as de@formal), but it will not be connected to informal variant and it will need to be translated separately. It will be quite easy, as Weblate provides shortcuts to preview and copy translations from similar languages, but still, each translation will need to be reviewed and copied manually. Having a fork and sync changes from upstream will probably require less work, but it is also less convenient and confusing (especially for community contributions).

                      I'm not sure what kind of tooling is used for Spanish language pack, but I feel like a formal variant seem to lag behind informal translations. And since release bot does not handle 2 variants in one language pack, changelog ignores completely existence of formal variant.

                      So... I'm not really sure what solution would be the best. But I'm leaning towards adding language to Weblate and then decide whether it should be hosted in separate repository or in the same way as Spanish.

                          rob006 I think @Kakifrucht stated previously that he’s not interested in maintaining a separate formal version of the German language pack. So it would need a different person looking after it anyways. So I think of there is someone willing to take on the work hosting it separately on weblate would make most sense.

                            I'm currently in the process to provide a formal translation for core and first party extensions, while improving the translation (with GPT magic 🪄) in general. I'm also willing to provide both formal and informal translations for Flarum updates.

                            When I'm done, is it possible for you to resync Weblate with my changes since I'm doing them offline @rob006? Not sure how to handle the formal variant, currently I'm creating another core-formal.yml that only contains strings with changes. I could merge them and provide all files with changes for you to bootstrap the de@formal variant.

                            Optimally Weblate would export them into one and have a toggle in admincp, maybe @Darkle could weigh in here about how he handles it in the spanish pack.

                              Kakifrucht Optimal format would be a copy of all translations in separate directory (so the same files structure as in https://github.com/flarum-lang/german/tree/master/locale with translations adjustments). But please avoid committing your work directly to language pack repository (or changing repository structure) - bot is very fragile and I'm not sure how it will react on unknown files, so any change in language pack will need to be synchronized with bot adjustments. Forking https://github.com/flarum-lang/german and working on fork would probably be safer approach.

                              Meanwhile I will think how adjust bot (and process in general) to better handle language packs with two variants.

                                  rob006 wouldn't a continuously diverging fork be the easiest? The formal fork can keep pulling changes from the informal upstream and apply changes. Can weblate work like that?

                                      luceos No, Weblate integration is unidirectional, so fork would need to be managed manually, by editing YAML files.
                                      It is probably possible to automate propagation from informal to formal using Weblate API, but it sounds quite complicated, and I don't have to implement this.

                                        The optimal implementation would probably be to have a formal repository that only contains/outputs files/strings that contain translations. Then in this method we modify it to check whether formal is enabled in settings, and if so we override the formal translations over the informal ones, since they are mostly the same anyway.

                                        Question here would be, does the Flarum translation system handle this without much custom logic having to be implemented, and does your Weblate system handle not outputting anything if translations haven't been done?

                                        If not, having two separate language repos is a bit of a pain to maintain, as people would have to provide them both when they make changes to third party extensions. I don't have a problem with maintaining core and first party this way, it would be mostly copy and paste anyways, but the main reason to use Weblate here was to simplify collaboration, and this naive approach would be clunky.

                                        About my offline updates, I have not changed structure for the informal variant. Can I just push all the changes I have and the bot syncs it to Weblate? I can also just push them to a branch if that helps you. Other than that, I have the formal variant ready for core and first party ext's.

                                          Would it be possible to modify the core translation system to allow for fallbacks to other language packs? The formal language would only contain formal strings and all missing strings would fall back to the informal variant.

                                          Using such a system the formal language pack would just require the informal one and define it as the fallback.

                                            Kakifrucht Sorry for the late reply, as @rob006 said, it's a fact that the Spanish formal registry is behind, the maintenance is much more tedious (especially after getting used to Weblate...) and is done as we all did before using Weblate, file by file, personally with some vscode extensions to facilitate especially the tasks of comparison with the informal registry to find updates or additions of new strings.

                                            Regarding conflicts with the bot, I have not had any problems, when changes are made to the formal registry, it is done directly in locale/en-ES-formal, so I doubt the bot knows about the existence of this file.

                                            Going back to managing a formal registry, I have to say it's not optimal and I've been looking for a long time for a better solution to handle this and improve maintenance/quality as it takes an awful long time to check everything.

                                            Kakifrucht The optimal implementation would probably be to have a formal repository that only contains/outputs files/strings that contain translations. Then in this method we modify it to check whether formal is enabled in settings, and if so we override the formal translations over the informal ones, since they are mostly the same anyway.

                                            This sounds really great, even if it would require manual maintenance, it would be a lot less work as it would only focus on the strings that need to be changed and their maintenance instead of everything, plus it would prevent the registry from falling behind as has happened many times with the Spanish formal one, better to use informal translations for the time being than nothing at all.

                                                  Darkle Just to be clear, I imagine the formal repository to still be setup via Weblate, with the difference that it doesn't just mirror unchanged translations, but simply doesn't output yaml translations keys if none are given in Weblate. This way we could still do the translations for both formats conveniently in Weblate by enabling both repositories to show up during the translation and would not require any mirroring of translations across the repositories.

                                                  I'm also unsure about pushing changes to the repo generally, irrespective of the formal translation, as I have made many changes to the informal translations offline. @rob006 please confirm whether I can just push them in or not if you need to manually merge them.

                                                  naxvog Fallback would indeed be another way to achieve this. It would probably be preferrable to handle it via the extend.php, if possible. We probably can do an override on the LanguagePack.php and LocaleManager.php to achieve this already. The only thing would be for Weblate to ignore untranslated strings. Maybe this is the default anyway, I'm not sure.