Translation (to Dutch)


#1

Hey fellow OctoPrinterinos!

I Do some FLOSS translating from time to time and I was wondering if there is any interest in translation to Dutch? I'm not a heavy user for octoprint these days,but it caught my attention that so little is translated for octoprint.

Don't bother (everyone is using English anyway)? Yes for Dutch?


#2

I've been deep-diving into the localization for OctoPrint lately, still trying to understand how it all works and the overall workflow required for building a language pack. Like you, I'm not seeing many language packs available. What's odd is that much work appears to have been done on the Transifex project page but this hasn't translated (pun intended) into the expected number of language packs. I would guess that others are equally confused regarding the process.


#3

Well, I found the description kinda atypical for a inexperienced person like myself.

Most translations i did so far (I'll type it up how I would do it for OctoPrint)

  1. Get Github account if you don't have one.
  2. Create a fork from /foosel/OctoPrint
  3. open /OctoPrint/translations/translations.pot language template wit a poeditor (poedit is my weapon of choice
  4. Translate
    5)Translate some more
  5. Save your translations as /OctoPrint/tree/master/translations/nl/LC_MESSAGES/messages.po (nl for dutch)
  6. When done, compile a binary translation; /OctoPrint/tree/master/translations/de/LC_MESSAGES/messages.mo
  7. when done and checked, do a push from your local drive to your github fork.
  8. Do a pull request from those two files to Foosel's branch

A git gui helped me the fist times for the pulling, pushing, commiting, ...., set up locally (gitkraken, ....) . I'm far from a coder, but like to contribute anyway.

Someone correct me if my methodology is wrong in this?

The transiflex project page is a bit confusing to me to. https://github.com/foosel/OctoPrint/wiki/Translating-OctoPrint this even more (a lot of hassle for getting a pot/po and editing it?)


#4

OK, I think I got transiflex figured out. Its a collaborative platform. Guess I'll be doing my translations there.


#5

Don't forget that there's a Transiflex CLI and you're supposed to be able to PULL whatever's in the cloud to your local folder. Maybe that helps create the .po perhaps.

It's suggested that something creates a package out of it. :man_shrugging:


#6

I've been meaning to set up a language pack repository (similar to the plugin repository) and have a cronjob autopull the Transifex translations daily and push them to the repository if there are changes, but I've simply not found the time yet with everything else going on all the damn time :sob:. I was kinda hoping someone else would do it if the need became too pressing but so far that hasn't happened either.


#7

I'd like to learn the process. Within the span of next year I'm reasonably certain that I need to eventually support four languages for this thing I'm working on. :cough:

Within my own work, I've been able to create two language files and to use yaml files to support those and then to bring them into both the backend Python and the front-end Kivy. And yet, this isn't how you're doing things and it would probably be best for me not to spin-up two solutions for the same functionality.

What I didn't see in your docs was how a plugin author is supposed to do localization. Maybe I've just missed it somewhere.


#8

Same mechanism as core localization really, at least if you use the cookiecutter template for new plugins (which gets utilized by dev plugin:new). That will pull in octoprint_setuptools to setup.py and in turn allow the same babel_* commands for translating stuff.


#9

I'll spend more time deep-diving your code and the docs.

I'd have to say that it's the programming recipes/workflow that I'm missing from what you do. As a teacher, this is what value I gave to my students: the list of commands that I would routinely do in different situations. The Internet is full of great advice about the details of programming but not the method itself.

I'm reminded of Jacques Pépin's La Méthode where he broke down discreet methods you'd use as a chef and each have their own ID. So for an alfredo sauce, you'd have to refer first to the Béchamel method and then return to the method for this sauce.

For me, I almost need to create a cheat sheet of methods for the things that occur within the OctoPrint development space.

Method 1:

Use the virtual environment that OctoPrint is installed into:

  1. Remote into the Raspberry Pi
  2. Optionally, change to the working directory of a plugin
  3. source ~/oprint/bin/activate

Method 2:

Finish using the virtual environment:

  1. deactivate

etc

I'll get there, though. I've got a couple of weeks to play around in this.


#10

Hey, thanks for both your replies. I'll dive into it next week and try to do a step by step writedown when I get the hang of it.