Are there plans for making A3 and A4 available for translation?

[kwahoo]

Hi,

This is a question both for realthunder and Zolko. As far as understand, both external workbenches Assembly3 and Assembly4 cannot be easily translated as described on the Translating an external workbench page?

Are there plans for including support of translation via *.ts files? Or you are too busy with core work, but you would accept PR's introducing translation support?

Excuse me if the topic was discussed earlier. Because of double meaning of "translation" word (second is "motion of a body" of course), search engine was pretty useless.

[Zolko]

Are there plans for including support of translation via *.ts files? Or you are too busy with core work, but you would accept PR's introducing translation support?

There is issue #173 covering this question. If you can take 1 file and propose an implementation to see how it goes would be very nice. If so, please make the PR against the development branch.

[Thowil]

Hi,

I just created PR #203 hoping that it will be helpful.

Also: Since this is my first post here (after quietly reading along for a couple of years...), I'd like to take the opportunity and say hello to everyone!

[chrisb]

I just created PR #203

Welcome to the forum. A pull request is of course the most welcome entrance ticket .

[kwahoo]

Wow, that was fast!

Thank you all for your effort. The topic seems to be more advanced tan initially thought https://github.com/FreeCAD/FreeCAD-addons/issues/187

[Zolko]

I just created PR #203 hoping that it will be helpful.

thank-you for that, but .... that's a lot of extra code: do we need to add them for each file and command ? Is it really worth the complexity ? The code becomes much less readable.

[Thowil]

...that's a lot of extra code: do we need to add them for each file and command ? Is it really worth the complexity ? The code becomes much less readable.

Sorry, I completely missed the post here...

Basically, Asm4_translate.py should be imported in all files containing strings which need translation.
This brings in the two translation-related functions and also makes the Asm4-translation-path known to Qt.
Imho the problem with translation is not so much that it introduces complex code (it's just wrapping strings in a function call after all), but rather that it feels like adding a lot of ballast all over the place.

There might be ways to make things look cleaner and hence enhance readability (maybe by creating a new variable for all translated string or the like) but in the end all strings need to be wrapped one way or the other.

Personally, I find QT_TRANSLATE_NOOP to be especially "hard on the eyes", but didn't find a good way around it, as pylupdate doesn't seem to support multiple aliases for translate in a single run...

[Zolko]

Imho the problem with translation is not so much that it introduces complex code (it's just wrapping strings in a function call after all), but rather that it feels like adding a lot of ballast all over the place.

OK, I understand. Well, let's try. BUT: the animation functionality is in heavy development right now, could you please exclude it from your translation PR ? The other functions are stable therefore we'll need less of intervention (except for the help, but this could be a good moment to do something about it)