Also, I need to acknowledge that @aholzhammer has reached out to me in private, and given me some help within his current possibilities, mainly some hints as of what hardware to use.
Good luck to him for his enterprise!
As mentioned above by @roidesreines I have built my Hanimandl based on Roland Rust’s excellent work with a 38 pin esp32 WROOM and a 2.4 inch 320x240 ST7789. My project displays only English now, including menus and information. I have translated into everyday English, for example I have used Overfill for Kulanz rather than Goodwill, which the dictionary says is the right translation.
I edited the code somewhat and disabled the jar counter as I don’t need it. I have also removed any code for the unused display types and reduced the user types from 3 to 1. This has made the code quite a bit shorter. I also changed the default jar types to UK ones as we have different sized jars here.
I haven’t translated the code at all as I didn’t see the work would have been worth the effort and it would have been too easy to break something. I have added comments in English in some places to help me understand the code.
The hardware is built on a small project board: RkEducation 5x7cm PCB Copper Matrix Prototyping Stripboard
They are also available on Amazon UK.
A proper PCB would be wonderful… there is a bit of “knitting” on the project board to link things together!
I am very happy to share my hanimandl.ino file if anyone wants it… you will need to change the jar sizes to suit your country. Is there a software repository on this site? I couldn’t find it.
Once again I wish to thank the original creators of this project.
Breaking news (at least for me).
As I was about to commit in downloading a version of Hanimandl and start to translate, I found out that Roland Rust is still very much active on the project.
Indeed, he even has just uploaded a work in progress version in his development branch where is he taking a shot at implementing multilanguage support.
If anyone has the opportunity, I’d love to get in touch with the guy to try and organize something.
I know this is a shot in the dark, but I’d better coordinate efforts here.
Thank you. We’ve just reached out to Roland at HaniMandl upstream maintenance · Issue #2 · RolandRust/HaniMandlWroom · GitHub.
HI !
Do you have some overview of the components you use !
Your stuff looks nice.
Georg
Hi,
yes, I am working on the translation to other languages. At the moment, this is implemented using a header file, and you have to decide before compiling if you want to use German or English. Not the nicest solution, but for my needs it is enough as a starting point. 
Note: Be careful with the development branch. There is also a new function implemented for the Servo regulation, and it’s not fully tested yet.
BR
Roli
1 Like
The compilation time way to choose the UI language is good enough for open source.
Since it is intended for users to understand at minimum how to adapt to material, thus tinkering a little bit with .ino files.
I’ve already worked on a version of the resources_fr.h containing dialogues, I’m just waiting for my LCD 320x240 screen to arrive to start the code and translation process from Roland’s dev branch.
I’ve also seen that he started to translate some file names to english, things are on their way, very nice!! 
2 Likes
Quick update here:
Today I have translated the entire commentaries inside the code. I worked on the last version of @Roland 's dev branch, dated from 3 days ago. Yes I used a google translate more than I’d like to admit, no it’s not perfect and yes it will do the job. 
I think it will be good when native German speakers who are familiar with the project have a look into it to catch the inevitable mistakes I must have made.
Next up is the translation of functions and variables.
To not mess up too much the code and avoid redondances, I plan to gather up all functions and variables inside a good old spreadsheet with their proposed translations and submit them here (or some more appropriate place someone would be kind enough to point me to) for the general public to make suggestions and rectifications to.
Coming soon.
Hi @roidesreines,
Thank you so much for contributing!
I am not sure if I get this right. By “function names” and “variables”, are you referring to symbols in code? This is a detail you usually do not translate into different languages, and it is a well established convention to use the English language. Maybe it is a misunderstanding on my end?
With kind regards,
Andreas.
Most are German atm, thats the “problem” … ;-)
Oh, I didn’t get that. Then, go ahead, @roidesreines! That’s also a thing I wanted to improve on the upstream version.
Jos (in the Facebook group) has translated the display messages to Dutch, no clear if it is publicly, but try to get the version!
1 Like
Ja, das ist schon so, das die Funktionen und Variablen fast alle auf deutsch sind. Habe das so übernommen vom Original Code. Mit aber ein wenig Fleissarbeit sollte dies zu ändern gut machbar sein. 90% von den Variablen sind ja von Zeile 370 bis 450 definiert.
Nun mal eine kleine Erklärung wie meine unschöne Implementierung von den verschiedenen Sprachen ist.
in der Zeile 155 wird die Sprache ausgewählt. Für jede Sprache gibt es eine Nummer
#define LANGUAGE 1 // 1 = Deutsch
// 2 = Englisch
Ab Zeile 229 wird das Sprachfile ausgewählt.
#if LANGUAGE == 1
#include "./Resources/resources_de.h"
#elif LANGUAGE == 2
#include "./Resources/resources_en.h"
#endif
da muss für das neue Sprachfile einfach ein neues #elif LANGUAGE == X definiert werden.
Dies währe dann schon alles, was im Code geändert werden muss für eine neue Sprache.
Nun muss nur noch das neue Sprachefile im Orden ./Resources erstellt werden (z.B. resources_fr.h).
Zu beachten ist, dass es von dem Display her Einschränkungen mit der Länge gibt. Ich glaube bei den absoluten Positionen ist es so gemacht, das es immer kürzer werden kann und die Position noch korrekt ist. Aber wenn es zu lang wird, kann es zu Überschneidungen kommen oder zu ungewollten Zeilenumbrüchen.
wenn der Text zentriert ist wird bei zu langen Wörtern rechts und links abgeschnitten (Kommt daher, das die Berechnung bei der x Position dann ins minus geht). Und zum Schluss muss man im UTF8 Zeichensatz bleiben. Ansonsten gibt es bei der Zentrierung einen Shift nach links.
Ich werde mir nach meinen Skiferien auch mal Gedanken machen, wie man das Node MCU Board als Hardware Level und der INA code in die upstream version bekommt. Sollte eigentlich gut machbar sein für das OLED Display.
1 Like
Hi Roland,
das liest sich gut.
Das mit der Sprachzuordnung so hemdsärmelig über das Header File zu machen, finde ich absolut in Ordnung.
Hautpsache die Symbole bekommen sprechende Namen und wir kommen von Konstantennamen wie PS_MI01, ST_TI01, SC_TO01 usw. weg: Ich würde mich an der Englischsprachigen Variante resources_en.h orientieren, und die Dinger CALIBRATION, FILL_QUANTITY, SERVO_SETTINGS usw. nennen, sonst bekommt man üble Hirnverzwirnung beim Lesen des Quellcodes, wegen der ganzen magic numbers.
Dass beim Übersetzen auf Embedded Geräten viele Dinge berücksichtigt werden müssen (Zeichensatz sowieso, aber auch Textlängen usw.), ist klar, und war zu erwarten. Vielen Dank für die ausführliche Beschreibung der Dinge, die es dabei zu beachten gilt. Das ist ein heißer Kandidat für einen dedizierten Abschnitt in der Dokumentation, damit andere beim Beitragen von Übersetzungen nicht unnötig stolpern.
Stark, vielen Dank. Sag bitte rechtzeitig Bescheid, dann kann ich mich u.U. vorher noch um die Integration von Improve multiboard-support · hiveeyes/hanimandl@1acc542 · GitHub kümmern, bevor Du loslegst. Das macht das Einbringen weiterer Hardware-Varianten einfacher als bisher, und kommt ebenfalls von der Verwendung von “magic numbers” weg: HARDWARE_LEVEL == 1 (vorher) vs. HARDWARE_LAYOUT_LEGACY, HARDWARE_LAYOUT_MODERN, usw. (neu). In diesem Sinne würde sich dann eine Konstante HARDWARE_LAYOUT_NODEMCU anbieten, um eine typische Hardware-/Pinbelegung für die von Dir verwendeten Geräte abzubilden. Schöne Skiferien erst einmal!
Viele Grüße,
Andreas.
code translation.xls (14 Ko)
Hi all.
Here is my first sweep on all German expression I felt needed to be translated and my first take on translating them.
[edit] I’ve already caught the Tara = tare mistake
Hi everyone,
As I will be away for the next 2 weeks, I think it is a good idea that I deliver the version with commentaries translated, even though I didnt have the time to translate any of the functions and variables.
This way, I hope that people who would like to work on the project meanwhile can already do it on the partially translated version, as to avoid having to transfer progress from one version to another.
hani-mandl-wroom-translated-commentaries.ino (186,3 Ko)
I have named this version W.0.3 as to respect the current naming convention.
Here is also my translation of GUI to French. I checked it for OLED 128x64 displays only.
resources_fr.h (3,5 Ko)
I’m really not sure that this is a good place to upload all this, but I must say that I am completely ignorant of the correct way to share these files. Please forgive me if that is not appropriate.
1 Like
Now I have a few issues, questions and commentaries to make:
-I have not been able to get my TFT display to work. The pin defintion in the current code for display type 3 doesnt make sense to me, and I didnt have any time to dive into that subject. Also I noticed that I ordered a ILI9341 version instead of a ST7735 version. May they be compatible? If anyone has a quick answer to that, I’ll gladly take it.
-I think that it would be a very very good idea to include an explicit mention of the license Hanimandl was developed under inside the code itself. I myself only very recently found that licensing while doing my research in the archives. I think this is less than ideal.
-I think it would be a very good idea to include the types of jars definition within the resources_**.h files. This way the denomination for jars could be directly translated with the rest.
This is all for now, I’ll check back in about 2 weeks!
The code under GitHub - hiveeyes/hanimandl: HaniMandl ist ein halbautomatischer Honig-Abfüll-Roboter. is developed for an OLED display, not for TFT, see HaniMandl, halbautomatischer Honig-Abfüll-Roboter - #4 by clemens !!
We had some issues with the license because the first author wrote some lines, but it was no standard license. But @Andreas nailed it down now and we have a dedicated license. Good idea to mention it within the code.
Hi there!
Just a quick update.
I’ve been very beesy with the beekeeping season starting much earlier than anticipated, so everything got delayed on my side.
I have finally translated the code itself. Variables and functions now have English names.
Code translation is done, but I haven’t found the time to do any testing, it might be completely broken.
I’ll try and get to it ASAP. I will be testing on both TFT 320x240 and OLED 128x64.
Just let me know if you wanna have it before that.
Maybe @Roland would be interested to look into it, since my translation is based on his dev branch?