search

dprojects / Woodworking

This is Woodworking workbench for FreeCAD
MIT License
200 stars 17 forks source link

Improve translation support #45

Closed hasecilu closed 3 months ago

hasecilu commented 3 months ago

Initially @kaktusus, me and other FreeCAD users tested the translation support on this WB and realize that it was not working, the translations of commands MenuText and ToolTip were not being shown on FreeCAD. After some changes we realize that replacing QT_TRANSLATE_NOOP() with translate() makes it work.

There is progress for Polish and Spanish translations but still not finished, problably in the next weeks we're able to finish it.

kaktusus commented 3 months ago

@hasecilu Thank you for preparing this PR and for your commitment.

@rafi612 and a @kadet1090 were also involved in the work, thanks to who we finally achieved success. :1st_place_medal:

Darek, we are looking forward to the merge. :wink:

dprojects commented 3 months ago

Thanks for your hard work but there are several issues:

kaktusus commented 3 months ago

ad 3. The script is intended to facilitate the handling of translation updates and such a tool is a valuable addition. ad 2. you are correct ad 1. I think we've already talked about this before and you presented your point of view in greater detail is right in principle, the currently available version should have translations available

:wink:

dprojects commented 3 months ago

ad 1. I think we've already talked about this before and you presented your point of view in greater detail is right in principle, the currently available version should have translations available

Yes, we were talking about it but translation is not easy problem to solve as I see.

In my opinion the translation should be done only for stable releases and should be kept outside the repository. This approach solves the problem with translations update each time the code is changed.

You think the translation should be inside the repository. Partially, I agree with your point of you, because it is more elegant and easier for end user to have it all together. But there is manage problem. Keeping Polish translation in master branch might be easy because it is single known language for me, so I would be able to update the file each time, before stable release. But imagine several unknown languages, it is impossible to update all of them.

So, I would rather recommend to keep the translations outside the master branch and they all should be available for download for each stable releases.

ad 2. you are correct

I tested QT_TRANSLATE_NOOP before and it was working, so this might be configuration problem or new FreeCAD version bug, if you found it not working. If the FreeCAD documentation will be updated, I change all the instances before new stable release. However, I also plan to update code, because not all drop down menu entries can be translated.

dprojects commented 3 months ago

To sum up:

Is it OK?

kaktusus commented 3 months ago

No hej Darku. :smiley:

Masz osobliwe podejście do tematu. I zastanawiam się czy nie komplikuje wszystkiego. Twój cel rozumiem.

Zwróć uwagę jak funkcjonuje zarządzanie tłumaczeniami w innych zewnętrznych środowiskach pracy. Jako przykład posłuż się środowiskiem każdym z dostępnych w repozytorium freecad-addons z platformy Crowdin. Nikt się na nic nie skarży wszyscy są zadowoleni, użytkownik jak zauważyłeś wcześniej dostaje gotowe rozwiązanie. :bangbang:

Podpowiem Ci jeszcze, że aktualne zmiany, które są proponowane w tym PR są testowane od kilku miesięcy. Pozaglądaj kiedy dostałeś ode mnie informację uprzedzającą o pracach testowych ... to było dawno temu. Zakładam, że wszyscy pracujący nad dodaniem tłumaczeń GUI a w szczególności hasecilu i ja (to pewnik) pracują na wersji rozwojowej. I rozumiem że chcesz wszystko sprawdzić samodzielnie. To słuszne podejście.

Jeśli nie jesteśmy pewni wyniku, nie powstaje PR. Obecnie jesteśmy na etapie przygotowanie tłumaczeń dla popularnych zewnętrznych środowisk pracy, które są nadal utrzymywane. Możesz uważać się za wyróżnionego autora, który otrzymał takie własnie wsparcie.

Z mojej praktyki odpowiem, że twoja propozycja (wersjonowania) ma głęboki sens, ale w obecnie stosowanym przepływie pracy nie ma znaczenia. Pozaglądaj np do Fasteners i SheetMetal pod kątem właśnie wymiany stringów i aktualizacji tłumaczeń z Crowdin w stosunku do wprowadzonych zmian w kodzie. To nie generuje potwornie wiele pracy autorowi, więc nie musisz się martwić że cyklicznie, często będziesz zmuszony akceptować PR z tłumaczeniami z Crowdin. Będzie to miało miejsce kilka razy w roku. No chyba, że postanowisz inaczej. Jeśli będziesz chciał ją wdrożyć z ciekawością będę obserwował Twoje wzmagania, mogę też Ci w tym pomóc.

Oczywiście jak wcześniej zauważyłeś kod może być modyfikowany bardzo często, a tłumaczenia nie koniecznie będą nadążały za tymi innowacjami. Skutkiem może być brak tłumaczeń dla kilku stringów GUI. Ma się to nieznacząco w odniesieniu do całości. To oczywiście moje zdanie. Jednak rozwiązanie, które chcesz zaadoptować może spowodować, że użytkownicy będą się krzywić, że tłumaczenia nie są dostępne bezpośrednio. Zauważ jeszcze, że źródłowy plik tłumaczeń pochodzący z Crowdin musi zostać skompilowany aby go używać w GUI... Poza tym użytkownik musiał by założyć konto na platformie Crowdin i umieć pobrać plik tłumaczeń. Oczywiście to nie jest skomplikowane ale spodziewam się, że będzie skutecznie odstraszało. :rolleyes: Nie musisz też być cenzorem wszystkich tłumaczeń. Na platformie Crowdin pracuje wiele osób (często zespoły tłumaczy dla wybranego języka, jak w naszym przypadku, nie zawsze jest to jawne działanie)_, tłumaczenia są jawnie dostępne i może je korygować każdy kto posiada konto Crowdin. Jeśli chcesz się zaangażować w przygotowanie polskiej wersji GUI dla WoodWorking to miłe, zapraszam na platformę Crowdin. Jako autor WoodWorking możesz w tym zakresie zrobić wiele dobrego. :wink:

Wątek instrukcji markującej _QT_TRANSLATENOOP, tak wszyscy znamy treść manuala dla programistów. Jednak z praktyki wiemy, że występowały pewne perturbacje w uzyskaniu pożądanego efektu po jej stosowaniu w zewnętrznych środowiskach pracy. WoodWorking jest kolejnym na aktualnie wydłużającej się liście, który otrzymał wsparcie w zakresie poprawy obsługi tłumaczeń GUI. Piszę o tym aby Cie poinformować, że nasze doświadczenie w tym zakresie jest coraz większe. Środowiska, które otrzymały to wsparcie, w pliku inicjującym, otrzymują inną instrukcję (już nie markującą), i jest to translate.

Przy okazji, "przygody" w trakcie pracy ze środowiskiem, którego jesteś autorem (niestety ponownie) spowodowały, że odświeżona została pewna nieścisłość (nie nazwę jej błędem) zalegająca w kodzie głównym. Być może dowiesz się o tym niedługo jeśli ten temat Cię zainteresuje. Jeśli ten problem zostanie rozwiązany z powodzeniem będzie można tą jedyną instrukcję markującą "wywalić" z twojego pliku InitGui.py :wink:

Takie mam spostrzeżenia. Może przybliżą Cię do obrania słuszych kroków, albo rzucą nowe spojrzenie na niektóre sprawy. Teraz musisz wydać werdykt. :four_leaf_clover: :disguised_face: Pozdrawiam serdecznie.

hasecilu commented 3 months ago

In my opinion the translations should be done only for stable releases, because the code will not change.

Do you have planned some release date? Or have a development branch to merge there? As of now when you download the WB from the FreeCAD-addons if uses the master branch so any chang on it will be delivered to users.

The QT_TRANSLATE_NOOP is recommended by the FreeCAD documentation, so you have to change this also if this is no longer valid.

You're correct, now I know the reason what it didn't worked before: because you added "MenuText" & "ToolTip" to contexts on QT_TRANSLATE_NOOP() making the translation not work because of the mismatch on the contexts. This is docummented: https://doc.qt.io/qt-5/qtglobal.html#QT_TRANSLATE_NOOP

class magicDowels():

  def GetResources(self):
    return {"Pixmap"  : os.path.join(iconPath, "magicDowels.png"),
        "MenuText": QT_TRANSLATE_NOOP("magicDowelsMenuText", "magicDowels"),
        "ToolTip" : QT_TRANSLATE_NOOP("magicDowelsToolTip", "Allows to add mounting points to the furniture. For example you can easily add screws, dowels, shelf supporter pins or custom mounting points."),
}

I'm going to fix it and check that it works, then I'll attend other points

dprojects commented 3 months ago

Do you have planned some release date? Or have a development branch to merge there?

If I see the FreeCAD 0.22 is available, I will try to test the master workbench with the FreeCAD 0.22 and release the stable workbench version 0.22. There is no roadmap for this.

As of now when you download the WB from the FreeCAD-addons if uses the master branch so any chang on it will be delivered to users.

Using master branch is risky, not-certified, not tested but should be fine. But if you want stable environment you need to follow versioning rules.

You're correct, now I know the reason what it didn't worked before: because you added "MenuText" & "ToolTip" to contexts on QT_TRANSLATE_NOOP() making the translation not work because of the mismatch on the contexts.

OK. Let me know if this is issue related to the code or translation. If there is code problem you can open issue or pull request to pint out the bug. Up to you. But this will impact only 0.22 not 0.21, because there is no backporting.

dprojects commented 3 months ago

Masz osobliwe podejście do tematu. I zastanawiam się czy nie komplikuje wszystkiego.

Po prostu nie lubię sobie robić niepotrzebnych problemów. Wrzucanie tłumaczeń do kodu spowoduje że nigdy nie będą działać. Żeby wypuścić wersję stabilną będzie trzeba czekać na wszystkie tłumaczenia, a nikt nie zna wszystkich języków żeby je wszystkie przetestować.

Nie będę wypuszczał nieprzetestowanego kodu bo nie lubię odwalać tandety i też nie chcę żeby pewnego dnia workbench przestał działać bo ktoś tam śmieci nawrzucał. No niestety ale projekty zarządzane prze społeczność bez testów, bez administracji, na zasadzie róbta co chceta, zazwyczaj kończą jako coś co nie działa.

Zwróć uwagę jak funkcjonuje zarządzanie tłumaczeniami w innych zewnętrznych środowiskach pracy.

To mnie w sumie nie obchodzi bo patologii w internecie jest wiele. Jest wiele projektów open-source które w ogóle nie działają i jest to właśnie efekt braku zarządzania i testowania kodu.

pracują na wersji rozwojowej.

I jak ty chcesz zapewnić w takim przypadku jakość jeżeli każdy pracuje na wersji jaka mu się podoba? człowieku jak każdy będzie robił co mu się podoba i wrzucał do mastera co mu się podoba to nigdy nie będzie działać... wersja FreeCADa jest określona dla wersji 0.21 i takiej powinno się używać robiąc tłumaczenia.

może spowodować, że użytkownicy będą się krzywić, że tłumaczenia nie są dostępne bezpośrednio. Zauważ jeszcze, że źródłowy plik tłumaczeń pochodzący z Crowdin musi zostać skompilowany aby go używać w GUI... Poza tym użytkownik musiał by założyć konto na platformie Crowdin i umieć pobrać plik tłumaczeń.

W takim razie zaraz stworze dodatkowe repozytorum jedynie na tłumaczenia i będę wrzucał tam pliki z Crowdin do których linki podeślesz. Wtedy jak będzie gotowe to zrobię wersję stabilną 0.21 i po sprawie. Tłumaczenia będą oddzielnie, będą też wersjonawane i każdy będzie miał do nich dostęp. Inni będą mogli też zgłaszać błędy w tłumaczeniach i wszystko będzie ok.

hasecilu commented 3 months ago

OK. Let me know if this is issue related to the code or translation. If there is code problem you can open issue or pull request to pint out the bug. Up to you. But this will impact only 0.22 not 0.21, because there is no backporting.

It is a code issue, check 424a15a4 commit, as you can see there the contexts were updated to make it work, there is still WIP so more changes could be need to be done, probably next weekend is finished.

dprojects commented 3 months ago

I have just created new repository Woodworking-translations. This repository will be dedicated only for translations. I will be able to make releases for translations only to keep it working with workbench (the same version). Also the community will be able report bugs related to translations. Also anyone will be able to download the translations without having account at Crowdin.

I am going to close this pull request but please send me links at Crowdin or anywhere to download translations, so I will be able to add the translations to the new repository and create 0.21 release, if everything will be fine. Please open issues at the new repository as well, related to translations.

I hope this will be fine, now.

kaktusus commented 3 months ago

Translation files source and compiled are available in this PR.

rafi612 commented 3 months ago

I don't know how this translations can be distributed in Woodworking as separate repository. As far as I know installing plugin in FreeCAD is just clone GitHub repository with all files (Translations blobs must be also distributed, because FreeCAD not building it, e.g in c++ .qm files are compiled by CMake at build time). Here we will have two repositories, each should be placed in different locations on target machine. Also translations should be properly "connected" with plugin source code for each versions. Different releases of plugin may need different string aliases e.g if something was changed, displayed string will broke.

Edit: Git VCS supports "submodules" which is importing another repository as folder in main repository, but i don't know if FreeCAD support cloning repository with "recurse submodules" option. Problem with version releasing also exists in this case.

dprojects commented 3 months ago

Translation files source and compiled are available in this PR.

Create pull request only with translations files at Woodworking-translations repository, so I will be able to merge them there.

dprojects commented 3 months ago

I don't know how this translations can be distributed in Woodworking as separate repository.

They can be in separate repository for download, also I will be able to make release for translations only. But also before making stable release of workbench I will be able to copy those translations into translation folder so they will be delivered together with the Woodworking workbench.

Here we will have two repositories, each should be placed in different locations on target machine.

Don't worry, I tested my own translation before and I had to put files into translation folder only.

dprojects commented 3 months ago

I created 0.21 branch and there are sample translation files. The menu entries and tooltips not working but info screens and menu name is fine. I will add update tool so end user will be able to update translation from the exact branch.

dprojects commented 3 months ago

I added template files at 0.21 branch, so you can translate them because they are created from 0.21 Woodworking stable version. I also added tool for automatic translation update, so this will be available at 0.22 version.

Good luck with translation ! Have fun !

hasecilu commented 2 months ago

Hi, sorry for late response, I was busy on other WBs, also with translation support.

From what I see your release model seem to be a single release for every FreeCAD minor release, this is helping you to make sure your WB is properly supported. Since you already released the WB compatible with 0.21 stable version probably you're not planning on releasing another version any soon and that's fine. Most of WB follow a "rolling release" schedule, preferred but prone to breaks which means it needs more maintenance.

As you may already know FreeCAD will release the 1.0 version "soon" which will bring huge improvements on FreeCAD ecosystem reason for me to trying to contribute to the ecosystem.

I see the option to manage the translations on another repository quite "overkill", the way in which the WB system works expects to have all needed translations files on the same repository, trying to do it differently just complicates the things for everyone, specially users.

As I mentioned before: pushing this changes to master branch will provoke that users downloading the WB on the Addon Manager download also the translations which in essence is a win for users. But if you prefer to only release new changes in a single big release later in time I think the best option is to create a development branch in this very same repository where contributors/devs/hackers can send patches, users will not get those changes so no worries about breaking user models, etc.

The work that I previously sent covered mainly commands, menu and toolbars but I saw there are hundreds of more untranslated strings, so even the translation support is done there is a lot still to translate so it could take a while reason why there is no special hurry to release all of these soon.

Code can still be enhanced, for example: 

            info = ""
            info += "<b>"
            info += translate('debugInfo', 'Note:')
            info += "</b>"
            info += "<br>"
            info += translate('debugInfo', 'CTRL-V - to paste it at your forum topic')
            info += "<br>"
            info += translate('debugInfo', 'CTRL-A, CTRL-C - to copy again')
            info += "<br><br><br>"

Can be rewritten as:

            info = translate("debugInfo",
                            "\n<b>Note:</b><br>\n"
                "CTRL-V - to paste it at your forum topic<br>\n"
                "<br>\n"
                "CTRL-A, CTRL-C - to copy again<br><br><br>"
                        )

This makes the strings generated for translation easier to read & translate when they are grouped as paragraphs versus when they're separated. Also when need to include variable inside is better to use format(), example: translate("context", "Moved {} cm").format(str(var))

For sure there are various things that can still be enhanced in the workbench, one quiet relevant, I think, is the MenuText and ToolTip string, so if you think some can be rephrased to be more descriptive (if needed) I think it's a good time to do those changes before proceeding at full with the translation.

So, we can take our time to enhance UX on the WB as best as possible, maybe we need a little of planning to know how to proceed best so let me know what do you think. Greetings.

dprojects commented 2 months ago

Since you already released the WB compatible with 0.21 stable version probably you're not planning on releasing another version any soon and that's fine.

I am going to release 0.22 version but the FreeCAD 0.22 is not released yet.

just complicates the things for everyone, specially users.

In Woodworking workbench version 0.22 user will be able to download translations with single click from menu.

on the Addon Manager download

I am not responsible for FreeCAD applications and their support. Addon Manager could be much better done.

the MenuText and ToolTip string

After latest commits, in 0.22, they can be translated.

hasecilu commented 2 months ago

I am going to release 0.22 version but the FreeCAD 0.22 is not released yet.

And probably will not, FreeCAD is going to release 1.0

I have this other branch that does not contains translation but the some code fixes, mainly for the MenuText and ToolTip contexts. https://github.com/hasecilu/Woodworking/tree/fix/translation_preparation

Want a PR on this repository?

dprojects commented 2 months ago

And probably will not, FreeCAD is going to release 1.0

so this next Woodworking workbench release will be 1.0

I have this other branch that does not contains translation but the some code fixes, mainly for the MenuText and ToolTip contexts. https://github.com/hasecilu/Woodworking/tree/fix/translation_preparation Want a PR on this repository?

This is fixed in master branch and will be available in next release version. There is no backporting for Woodworking workbench version 0.21, MenuText and ToolTip not work there but the popups can be translated and also most of all tools, so if you are interested, you can translate .ts files at 0.21 translation branch, if the FreeCAD 1.0 will be released the 0.22 translation branch will be removed and created 1.0, no matter in fact.

You can't add translation files to master branch and patch them because .ts files refer to code lines and code itself, if the master code will be changed you have to create new .ts files, not only edit them. Trying to "patch" those files is not right approach, this idea behind you scrip to add only new strings is very naive, sorry.

hasecilu commented 2 months ago

Let's target the efforts for next release.

The main usage of line numbers on the ts is for translators to be able to see the context on Qt Linguist program, also works for .ui files that are even rendered. The important files are the .qm they contains the translation and don't contains metadata as line numbers, so is safe to change either the code or the .ts files and translation will continue working.

Feel free to use those changes when you need them, meanwhile I'll be checking translations on CrowdIn.

dprojects commented 2 months ago

The main usage of line numbers on the ts is for translators to be able to see the context on Qt Linguist program, also works for .ui files that are even rendered. The important files are the .qm they contains the translation and don't contains metadata as line numbers, so is safe to change either the code or the .ts files and translation will continue working.

But the strings for translation can be changed or removed, not only added, so this approach of adding only will be invalid. You can try update it manually but this is tracing each commit and correct all those files each time, wasting time.

Translation for commercial product can be in master branch because they employ translation team with schedule and target before release. This project is different because it is based mainly on volunteers and work without pressure or time limits, so the master development branch is not exact place.

Let's target the efforts for next release.

It is up to you.