Update for translation strings and translation files

[DivingDuck]

The translations need an update to reflect all the changes that happen during the past year. In addition I extended the translations especially for Pronsole as this is now part of the binary distribution. The general translation template was generated with pygettext.py and all translation files was updated with Poedit.

Modifications in detail:

pronterface.py:

• Add more translation strings.
• Fix wrong translation string that cause pygettext.py an extraction error (Line 1748).

projectlayer.py:

• Minor update for a tool tip string

pronsole.py:

• Most of strings are translatable now.
• Line 851, add baud rate 250000 for complete_connect

Translation files:

• Removed plater localization files for all languages

• Updated general translation template

• Updated translation files and deleted unused translation strings for all existing localization's.

• German translation is 100% complete. Review is welcome.

• All other language translations need an update from translators.

.gitignore: Slightly updated.

Something we may should think about is whether and how we should bundle translation files to an official release. I recognized that older versions of translations are partly not compatible with actual state of source code (and vice versa). Maybe we can add automatically a zipped locale folder via action chain to the distribution. A user then can download a compatible file set if needed and will possibly contribute a more completed / updated translation or add additional translations.

[rockstorm101]

I'm happy to merge this PR already, great work, many thanks. I'll wait in case you want to add anything else.

Something we may should think about is whether and how we should bundle translation files to an official release.

Very good point. I didn't even realize we weren't shipping translations. There's probably a way to include them using the 'setup.py' process? However, since we should migrate away from setup.py anyway (see #1319) it might be better to implement both things on the same go?

[neofelis2X]

Hi, really great work! I was flying quickly through the german translations and noticed only one point where I would propose a change. And one minor typo.

[DivingDuck]

I'll wait in case you want to add anything else.

Yes please. I want to take a bit more time for looking around in case there are more missing translations or maybe needed corrections like those of @neofelis2X pointed to. Lets say for the next week.

it might be better to implement both things on the same go?

This is a good idea. There is still a point that I didn't understand. Back in the days there was a distributed translation package with .mo files. There was a decision taken not to distribute those files. Did you know what the problem was with those files?

I was thinking about weather it is possible to automate the whole generation process but I actually think this is maybe not the best idea too (beside the point that I don't know how to do that for now).

On the other side, asking a normal user to download a locale folder from github manually, then expecting he is able to use a 3rd party application like Poedit for building his own .mo file set will possible overextend those users. In addition the translation folder needs to be located at a dedicated place depending on the used operating system. This is maybe the reason why translations are not used or most users do not know about it.

Anyway, guess, we will find a solution somehow. :)

[rockstorm101]

Back in the days there was a distributed translation package with .mo files. There was a decision taken not to distribute those files. Did you know what the problem was with those files?

The issue with the .mo files is that they are binary blobs that are (allegedly) machine dependant and therefore it makes no sense for us to store them in our repository. Somehow the installation (or packaging) process must generate them specifically for each user machine. See this question for a more detailed explanation.

I had a go at automating the creation of .mo files some time ago but wasn't happy with it in the end. PR #1339 explains what the debate was.

I totally agree that we must handle the translations instead of asking end users to generate anything.

[DivingDuck]

Ok, I got it. The explanation helps to understand the problem. I haven't an idea for solving it for now but try to find a way. Guess, I will do a bit of research.

[neofelis2X]

Interesting, I was also wondering why the .mo files are such a hassle and why almost all discussions about them are somewhat outdated or more than 10 years old. Can't we generate the .mo with github actions when we build the windows / macos version? I don't know how that would work for linux tho.

There must be some other cross-platform python projects that have found an elegant solution for this :]

[DivingDuck]

I did some more translations and fix an keyboard shortcut.

In detail:

readme.md:

• Slightly modified note for osx users: "right click" to "right- or ctrl click". See #1405

viz.py:

• Add more translations strings gviz.py:
• Add more translation strings

gcodeplater.py:

• Missing translation for line 97: Window title "G-Code Plate Builder"

gcview.py:

• correct string from "Fit to plate" to "Fit to view" and add long help
• add missing Reset view [R]
• made windows title translatable 'G-Code Viewer' line 527
• shortcut [+] works for numeric keypad, but not for keyboard Line 73:ZOOM_IN_KEYS = wx.WXK_PAGEDOWN, 388, wx.WXK_RIGHT, ord('=') Guess, this was a mistaken input, so I changed ord('=') to ord('+') This will take care that users w/o numeric key pad can use zoom with [+]

stltool.py

• add translation

stlplatter.py

• add some translation strings

Over all the translations strings increased from 603 to 792 up to now. I must say I'm surprised about the amount we already have (and it is still not complete (eg. gcoder.py what I will left open for now)

Some observations

My fault, I shouldn't do such tests :)

• Plate builder (for STL files): Shortcuts [+, -, R,F] do not work, only mouse actions for zooming are working how to rotate a stl in x or y? Z works with [shift]+[mouse wheel]

• G-Code Plate Builder (gcodeplater und gcview):

  • Shortcut [F] (fit) causes to an non breaking error message in console window while [R] (reset view) is working fine:

    Traceback (most recent call last):
      File "printrun\gcview.py", line 313, in keypress
      File "printrun\gcview.py", line 276, in fit
      AttributeError: 'GcodePlater' object has no attribute 'model'. Did you mean: 'models'?

  • Same happen for gcview (the normal gcode plate in main GUI) when pressing [F] while the gcode file is not completely loaded.

• gviz.py: line 89 SetToolTip this seems to be shown nowhere and isn't working?(slightly reworked): self.p.SetToolTip(_("Click [Mouse-Right] to move the view, click [Mouse-Left]to pan the view, scroll with [Mouse Wheel] to zoom, and scroll with [Shift]+[Mouse Wheel] to change the layer."))

• gcview.py: line 456 SetToolTip (same as gviz.py line 89): self.glpanel.SetToolTip(_("Click [Mouse-Right] to move the view, click [Mouse-Left]to pan the view, scroll with [Mouse Wheel] to zoom, and scroll with [Shift]+[Mouse Wheel] to change the layer."))

For all of those quirks I do not have a solution,

[rockstorm101]

Some observations

My fault, I shouldn't do such tests :)

Oh no, that's awesome we want the program to be as complete and bug-free as possible :)

I've opened bug #1410 to keep track of these.

[DivingDuck]

@rockstorm101, sorry for being delayed. There is still one point left in my list for this PR. Here is what changed with the last two updates:

#74fa0c2: My neighbor's cat came visiting me and proudly pushed his first update before I was ready to split the tasks - welcome Balu. :)

• pronterface.py:
  • During my tests I found an additional problem with keyboard short cuts that prevent inputs of some characters in the in the console window, is fixed now
• buildpackage-win.yml and release_windows.bat:
  • In addition I also fixed the low case for program names to capital case as @neofelis2X mentioned for your update in #1407 in the windows build action
• release_windows.bat:
  • add locale to distribution folder so that it is part of the file set for distribution
• gcview.py:
  • Delete spurious spaces as mentioned from you
• log.py:
  • more translation

https://github.com/kliment/Printrun/pull/1406/commits/ba3b293f1d05f3cfece0e8f495324022caabbc59

• buildpackage-win.yml:
  • The windows build include the translation files to the distribution package

The last point missing in my list is how to generate the *.mo files within the actions, that is the next thing I try to solve now.

Reminder to my self: You need to update all translation files once more as soon everything is done here.

[rockstorm101]

Hi @DivingDuck, what's the status on this? I guess no luck with producing the .mo files? Was that the only pending matter? If yes, what are your thoughts on merging this PR "as-is" and leave the .mo issue for another PR?

[DivingDuck]

Hi @rockstorm101, sorry for the delay. I had a quite busy month and took a break on eastern. Indeed, I didn't found a solution for the generation so far and Visual Studio hit me in addition before eastern after an update with crashes during startup. This is now solved with the latest update this week.

Anyway, it looks like I have introduce a bug with the translation activities. Guess there was a string I translate sometime ago that I better shouldn't translate (stopping a print do not stop printing activities). The error do not happen when I deactivate the translation and use the original language instead. I wasn't able to find the error before my break but planed to search for the error this weekend. As soon I find and repair this quirk I will update all translation files and we can release this PR.

The .mo generation can be done later.

[rockstorm101]

sorry for the delay. I had a quite busy month and took a break on eastern.

No worries, there's no rush, I've been away for a while as well which is always a sane thing to do.

Anyway, it looks like I have introduce a bug with the translation activities. Guess there was a string I translate sometime ago that I better shouldn't translate (stopping a print do not stop printing activities). The error do not happen when I deactivate the translation and use the original language instead. I wasn't able to find the error before my break but planed to search for the error this weekend. As soon I find and repair this quirk I will update all translation files and we can release this PR.

Great stuff, sounds like a plan. Let us know if you need any help.

[DivingDuck]

Some more updates...

67f5bc4:

Move user inquiry on first place before initializing the exit procedure, make the consequences of exit a print more transparent https://github.com/kliment/Printrun/issues/1415

6e79eba: When hit temp button Off for heater or bed a conversion error occurs and heaters won't go off: Error message: "You must enter a temperature. (ValueError("could not convert string to float: 'off'"))"

e25a971: Update translation master and language files.

[DivingDuck]

More changes.

https://github.com/kliment/Printrun/pull/1406/commits/e73448b512d72321014d3eb2badb44e33e3459b9 pronsole.py, set_temp_preset, self.temps, and self.bedtemps: Different notation in upper and lower case for filament types causes Pronterface to list double filament preset entries. Changed filament names to upper case.

86fb81f Update translation master and language files.

[DivingDuck]

This PR is now complete, at least I didn't find any new show stopper since my last update.

What is still missing is the .mo generation. Users can generate this manually with e.g. the free version of Poedit. The translations files are bundled with the distribution files for Windows since this PR (https://github.com/kliment/Printrun/commit/ba3b293f1d05f3cfece0e8f495324022caabbc59).