• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

GC little helper II (Translation)

2Abendsegler

Geomaster
Bevor die Informationen zu einer Übersetzung des GClh irgendwo verschwinden, stelle ich sie mal hier gebündelt zu Verfügung und zur Diskussion.

Wenn jemand Interesse hat, sich in das Thema einzuarbeiten oder bereits Kenntnisse mitbringt, dann können wir in absehbarer Zeit ein Projekt zur Übersetzung des GClh ins Leben rufen. Mit unserer derzeitigen Mannschaft können wir das aber vermutlich nicht stämmen. Und wenn sich keiner findet, naja, dann war es wohl auch nicht so wichtig und dann schauen wir dem Thread zu, wie er ziemlich langsam nach unten wandert. :D


Die Übersetzung am besten über einen Dienst wie Crowdin machen. Dann kann jeder ohne großen Aufwand helfen.

2Abendsegler schrieb:
@SammysHP:
Das sieht echt gut aus, danke!

Habt ihr das auch genutzt?
Wenn ich das richtig sehe, dann hat man 2 Monate freien Zugang, richtig?
Gibt es etwas, was wir besonders beachten müssen, Fallstricke oder so?
Ja, nutzen wir: http://crowdin.com/project/cgeo

Für Open Source Projekte ist es immer kostenlos: http://crowdin.com/page/open-source-project-setup-request


Ich muss noch einmal den Punkt Übersetzungen/multi-lingual aufnehmen. Aus beruflicher Erfahrung wird hier der Aufwand und die Dauer meist deutlich unterschätzt. Eine Unterstützung über ein Tool ist bei größere Umfang dringen erforderlich, um Aktualisierungen zu koordinieren. Damit die Texte auch immer aktuell gehalten werden können.

Ich freue mich schon auf die ersten Homonym oder ein Polysem, die machen immer besonders viel Spaß bei der Übersetzung bzw. beim Texthandling. Ich erinnere mich noch mit grauen an das Projekt, in dem der deutsche Text, der Referenzschlüssel war.

Ich sehe noch einen weiteren Punkt kritisch: die Skriptgröße; je nachdem wie viele Sprachen wir unterstützen wollen, wird die Größe des Skripts noch einmal deutlich anwachsen und damit auch die Ladezeiten und das bei jeden Seitenaufbau. Hier sollten wir uns noch einmal Gedanken machen, wie wir z.B. Texte bei Bedarf nachladen können.

Prinzipiell fände ich es aber gut, die Hilfstexte "auszulagern". Ich finde sich machen gerade den Teil mit den Settings extrem unübersichtlich.

Das waren meine 2ct

CachingFoX

@CachingFoX:
full ack, oder wie war das. :)

Ich hatte mir mal das Verfahren bei bei cgeo angesehen, naja nicht wirklich, nur halt so im Überblick, da was gelesen und da.

Es scheint dort so, dass die Texte in eigenen Dateien liegen, vermutlich je Sprache eine Datei (Punkt Scriptgröße). Dann scheint es eine Jobverarbeitung zu geben, die den aktuellen Bestand an allen Sprachen ins Crowdin läd. Crowdin scheint hier schon Programmsourcen zu Verfügung zu stellen um solche Arbeiten durchzuführen. Gleiches gilt für den Transport der Übersetzungen aus dem Crowdin zurück. Vermutlich werden die Transporte hin und zurück durch cgeo Mitarbeiter manuell nach Bedarf gestartet.

Wie SammyHP schon geschrieben hat, ist Crowdin für "Open Source" kostenlos. Auch wenn wir genaugenommen nach der Linzence kein "Open Source" sind, sondern "freie Software", dürfte das für uns auch gelten.

Eigene Übersetzer hier von den Forumsteilnehmern oder so werden wohl dann nicht benötigt, ich höre ein Aufatmen. Hier kann man wohl auf interessierte Crowdin Übersetzer hoffen, die dann auch an irgendeiner Stelle im GClh zum Dank benannt sein sollten, so wie es cgeo auch macht.

Womöglich können wir auch auf cgeo eigene Programmsourcen zugreifen. Die, ich glaube, Apache Lizence ist mir nicht geläufig.

Ich stelle mir vor, dass es einen technischen Hauptverantwortlichen geben sollte, der sich um das gesamte Thema Übersetzung kümmert. Damit meine ich nicht komplett in Eigenregie alles machen und entwickeln, sondern vielmehr ein Kümmerer (oder auch Projektmanager). Ich werde das nicht noch zusätzlich stämmen wollen. Womöglich gilt das auch für Dich. Bevor diese Person oder die Personen, mehrere wären ja auch ok, nicht benannt sind, wird es aus meiner Sicht zum Thema Übersetzung insbesondere keine Entwicklungen geben.

@SammyHP:
Du ließt ja hier mit, vermutlich.
Vielleicht kannst Du uns zu dem Thema bei euch einen groben Abriss geben, oder vielleicht kennst Du jemanden bei euch aus eurem Projekt, der das könnte. :D :gott:

Das waren dann 2 weitere ct von mir. :)

LG Frank

Ganz wichtig: Die Übersetzer kommen natürlich auch nicht von alleine! Da muss man schon Werbung bei seinen Nutzern machen, damit die übersetzen. Wir haben uns Skripte geschrieben, um die Texte hoch- und runterzuladen. Das wird mehrmals vor einem Release und ab und zu dazwischen per Hand gemacht.

Wir nutzen das Android-i18n-System, das nunmal für jede Sprache ein eigenes Verzeichnis will und die Strings über Ressourcen anspricht. Das muss man natürlich nicht so implementieren.

Der größte Aufwand dürfte sein, alle Strings durch entsprechende Lookups zu ersetzen. Am besten ein paar Funktionen schreiben, die man mit einem Identifier aufruft und die dann den Entsprechenden String zurück gibt. Schwierig ist das aber, sobald man Platzhalter hat. Dann muss man nämlich benannte Platzhalter verwenden. "Foo %s bar %s", "asdf", blubb" funktioniert nämlich in der einen Sprache, in einer anderen mag es aber "Foo bar %s %s" sein, wobei die beiden Strings auch noch vertauscht sind. Ebenfalls kompliziert sind Zahlen. Man muss nämlich nicht nur zwischen Einzahl und Mehrzahl unterscheiden, manche Sprachen haben Sonderfälle für Null, manche auch für andere Werte. Hier ein paar Infos, wie Android das umsetzt: http://developer.android.com/guide/topics/resources/string-resource.html#Plurals
Es müsste auch für JavaScript entsprechende Tools geben, die man nur einbinden braucht. Die bringen dann auch alle erforderlichen Funktionen mit.

Bezüglich "Open Source": Die GPL ist sozusagen der Ursprung von Open Source, zumindest die wichtigste Open Source Lizenz. Die Apache Lizenz von c:geo ist zumindest mit der GPLv3 kompatibel, weiß nicht, wie es bei der v2 aussieht, notfalls würden wir es dir halt erlauben. Aber viel helfen würde dir das eh nicht, weil es wenig Sinn macht, Strings aus c:geo zu übernehmen. Die sind halt immer sehr spezifisch für einen bestimmten Fall.

Um es nochmal zusammenzufassen:
- Alle hardcoded Strings aus dem Code entfernen und durch Lookups ersetzen (selbst oder mittels i18n-Framework).
- Strings exportieren und zu Crowdin hochladen.
- Übersetzer finden.
- Strings wieder herunterladen
Das müßten die wichtigsten Dinge sein. Falls ich etwas vergessen habe, einfach dranhängen.
 
Oben