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?
Actually it does with TFT on @Roland 's version. (this adds a lot of nice visual features and indications, nice work, it’s my favourite so far.
I did finish the translation of both code and commentaries.
The esp32 boots up, menus are scrollable.
I am yet to find the time to check it in depth.
Unfortunately it @Roland has updated his dev code to fix some bug meanwhile, I havent had the time to search for differences and integrate in my version before his goes too far ahead in development.
I fear having to learn the whole GIT and GITHUB thing in order to bring this project to a conclusion. If someone could do the code publishing for me, or at least point me the right way so that I can publish this translated code before it’s not anymore relevant it would be fantastic!
I will soon get to test everything in production conditions, my 1st harvest will be there I think in less than 10 days, first batch should be no less than 400kgwith 2 different jar sizes, that should be enough for testing purposes my plan is to have two units (mine from last year, reliable and tested) and the dev version to be able to switch in case there is some unexpected bug to deal with.
So I’m trying to get @Roland attention on this, he’s in the best place to help make this go forward!
Help!!
@roidesreines Ich weiss nicht von welchem Stand du vom Developer Code ausgegangen bist. Habe da noch einige Änderungen gemacht und eventuell noch neue Funktionen hinzugefügt. Ist halt ein bisschen blöd gelaufen wenn man vom Developer Code ausgeht und mehrere Personen Änderungen macht. Von der Integration der Sprachen habe ich und noch jemanden den Code noch mit Zusatzfunktionen ergänzt.
Aber mal sum Stand wie es heute ist. Der Code welcher nun im Developer Branch ist, sollte auch der sein, von welchem ich ein Release machen möchte. Muss den aber noch Live testen, was bei der nächsten Abfüllung gemacht wird (so in den nächsten 20 bis 40 Tagen). Wenn ich dann keine Fehler finde mache ich ein Release (Hoffe finde keinen Fehler ansonsten habe ich ein Problem 
).
Nun könnte man dann versuchen die Codes zu vereinigen. Aber da kommt dann schon das nächste Problem. Mein Code auf dem Computer ist schon weiter als der im Developer Branch. Bei dem bin ich schon dabei meine nächsten Ideen zu implementieren. ;al überlegen wie man das zusammenbringt. Aber die Variablen auf Englisch zu übersetzen hat ehrlich gesagt für mich nicht die höchste Priorität. Wenn das funktionier wo ich noch Implementieren will kann ich mir das mal überlegen was die Variablen nun für einen Namen haben sollten.
Here is what I came up with, maybe you’ll get inspired to do something with it.
hani-mandl-wroom-translated-commentariescode.ino (184,3 Ko)
resources_en.h (3,4 Ko)
resources_fr.h (3,5 Ko)
resources_de.h (3,8 Ko)
I am aware that some translation might be incorrect, and maybe I have broken the code a little ;)
This is just to show you what can be done with very little knowledge and a little bit more time and goodwill
I’m very willing to get this project translated, so if you’re okay to switch to english, I can redo some of the translation to allow you to work on your last versions in English from there on.
Also, I will have a few thousands jars to fill, so I can do some good testing.
1 Like
Also, I think the more precious work is commentary translation, functions and variables aren’t that difficult to translate with the right tools and understanding of the code.
@roidesreines habe heute mal ein neues Release gemacht von dem code. ich habe aber aich die Variablen für die Sprache seit einiger Zeit umgestellt. So ist dein Sprachfile nicht mehr mit meiner Version kompatibel. Wenn du Lust und Laune hast, darft du die gerne neü machen und mir zusenden. Ich werde diese dann einbinden. Was die Übersetzung im Code betrifft, ist es einfach blöd gelaufen. Ich war schon zu weit um dies noch Implementieren zu können. Hätte mir zu viel Arbeit gegeben. Würde aber gerne deine Übersetzung noch einbinden. Aber um die Variablen im Code zu àndern, müssten wehre wahrscheinlich erst im Release W.0.4 möglich, da mein dev Branch schon weit vor dem heutigen Release ist. Bin eben noch dran, den HM weiter zu automatisieren. Möchte da noch ein kleines Rondell bauen wo mit dem HM kommuniziert.
1 Like
I’ll do it, it’s easy enough.
That is fine with me, and I would be honored to help.
1 Like
Mittlerweile wird das Projekt auch in Polen bekannt gemacht https://mellifer.pl/projekt-hanimandl-pl/
Code unter GitHub - DeptalaPiotr/hani-mandl-PL es wurde – bis auf zwei default-Werte und ein weiterer splash screen – nur die Ausgabe von Deutsch auf Polnisch übersetzt, d.h. das könnten wir gut übernehmen!
Bei der Hardware-Beschreibung auf der Website muss man vorsichtig sein, und das sollte man so nicht machen! Dort wird Display und Rotary mit 5 V versorgt, was zumindest über den rotary zu 5 V auf den ESP-Pins führen wird, beim Display bin ich unsicher, ob das so ok ist, ungeprüft würde ich das aber definitiv nicht machen!
1 Like
Ich habe gerade gesehen, dass @Roland die kryptischen Variablennamen schon durch sprechende englische ersetzt hat, z.B. hier für die deutsche SprachversioN: HaniMandlWroom/Software/src/Resources/resources_de.h at development · RolandRust/HaniMandlWroom · GitHub sehr gut! Damit kann man zur Compilierungszeit die Sprachen umstellen, aber nicht bei runtime. Wollen wir das, oder ist der Aufwand dafür zu groß? Speichertechnisch sollte das so gut wie nicht auftragen im Vergleich zum restlichen code.
@clemens das mit dem runtime umstellen der Sprache sollte eigentlich eine Kleinigkeit sein. Man könnte ja ein kleines Script bauen, welches die verschiedenen Sprachdateien ausliest und dann die Main Sprachdatei erzeugt. Die würde dann in etwa so aussehen:
char TAREVALUES[][] = {"Tarawerte", "Taravalues", "..."};
char CALIBRATION[][] = {"Kalibrieren", "Calibration", "..."};
...
im Code könnte man diese dann mit:
TAREVALUES[i]
aufrufen. Wobei i dann der Wert ist welcher im EEprom abgespeichert ist.
Bin jetzt nicht der Profi c Programmierer, aber ich denke so sollte es klappen, damit man die Sprache runtime wechseln kann. Ob man das braucht ist eine Frage. Die wenigsten werden wahrscheinlich die Sprache wechseln.
1 Like
@clemens und @roidesreines in meinem dev Branche ist nun eine Version bei welcher die Sprache runtime umgestellt werden kann. Um den HM in eine andere Sprache zu übersetzen muss einfach eine neue Sprachdarei mit dem Namen resources_[xx].h erstellt werden. Das Script merge_language_files.py erstellt dann die Sprachdatei für den HM. Ich hoffe das ich den Code so angepasst habe, das man ohne Codeänderung eine neue Sprache hinzufügen kann. Es ist aber gut möglich, das ich noch nicht alle Variablen erwischt habe und es noch zu einigen Darstellungs Problemen kommen kann.
2 Likes