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

Textbausteine im Urwigo

nebbiolo

nebbiolo

Geocacher
Hallo

Ich möchte meinen ersten Wherigo in mehreren Sprachen anbieten, deshalb die Texte NICHT in der Bezeichnung oder bei den Meldungen hinterlegen.
Gibt es eine Möglichkeit dies mit Konstanten (z.B. Textbausteine) zu machen, mit LUA-Tabellen (wie im Forum erwähnt) möchte ich lieber nicht arbeiten, da komme ich schon mit urwigo an meine Grenzen ;-)

Viele Grüsse aus dem regnerischen Süden, Nebbiolo
 
kansu_makugen

kansu_makugen

Geocacher
Nimm doch einfach Earwigo! Das unterstützt von Haus aus Multi-Language-Texte, und das sogar (lauf Aussage des Erfinders) mit Auswahl zur Laufzeit.
Außerdem hast du dann auch nicht das Problem mit fehlenden "Sonderzeichen" wie Ä,Ö,Ü,ß, ç, ë, æ etc. (Ich hoffe, ich lehne mich mit den letzten drei Zeichen nicht zu weit aus dem Fenster, aber die deutschen Umlaute funktionieren ;) )
 
S

sTeamTraen

Geocacher
Kansu_Makugen schrieb:
Außerdem hast du dann auch nicht das Problem mit fehlenden "Sonderzeichen" wie Ä,Ö,Ü,ß, ç, ë, æ etc. (Ich hoffe, ich lehne mich mit den letzten drei Zeichen nicht zu weit aus dem Fenster, aber die deutschen Umlaute funktionieren ;) )
Zum Vergrößern anklicken....
ç, ë, æ sind (auch auf Garmin) von Earwigo völlig unterstützt. Für кириллица, 日本の, und 한국의 braucht man eine UTF-8 Plattform (d.H. allen, ausser Garmin).
 
docfred

docfred

Geocacher
sTeamTraen schrieb:
Kansu_Makugen schrieb:
Außerdem hast du dann auch nicht das Problem mit fehlenden "Sonderzeichen" wie Ä,Ö,Ü,ß, ç, ë, æ etc. (Ich hoffe, ich lehne mich mit den letzten drei Zeichen nicht zu weit aus dem Fenster, aber die deutschen Umlaute funktionieren ;) )
Zum Vergrößern anklicken....
ç, ë, æ sind (auch auf Garmin) von Earwigo völlig unterstützt. Für кириллица, 日本の, und 한국의 braucht man eine UTF-8 Plattform (d.H. allen, ausser Garmin).
Zum Vergrößern anklicken....

Hab ne Frage zu Earwigo:
Ich nehme an, dass ich nur am Start diese Sprachwahl machen kann. Oder täusche ich mich? Ich kann sicher unterwegs nicht noch einmal wechseln (auch nicht mit LUA nativ)?

docfred
P.S.: Hab grad ne Mini-Cartridge getestet. Ist ja wirklich cool!!
 
S

sTeamTraen

Geocacher
docfred schrieb:
Ich nehme an, dass ich nur am Start diese Sprachwahl machen kann. Oder täusche ich mich? Ich kann sicher unterwegs nicht noch einmal wechseln (auch nicht mit LUA nativ)?
Zum Vergrößern anklicken....
Doch... auf jedem Moment kann man die 1., 2., 3. usw. Sprache mit WWB_localize_n=1, =2, =3 auswählen.
 
S

sTeamTraen

Geocacher
Wie DocFred entdeckt hat, geht das dynmaisches Umstellen der Sprache nicht so einfach. Ich bitte um geduld während die Bugfix-Procedure... :)
 
docfred

docfred

Geocacher
sTeamTraen schrieb:
Wie DocFred entdeckt hat, geht das dynmaisches Umstellen der Sprache nicht so einfach. Ich bitte um geduld während die Bugfix-Procedure... :)
Zum Vergrößern anklicken....

Ich wollte hier mal kurz was in deutsch posten, das fällt mir leichter:

- Zunächst mal finde ich die Umsetzung der Mehrsprachigkeit in EARWIGO ist genial gelöst. Das wird man in Urwigo so nicht umsetzen können, da das Programminterface und die Zusatzfunktionen, diese automatisch in den lua-Code intergriert.
- Auch die Funktion, bei Start (nicht bei Restore) des WIG die Sprache zu wählen, ist genial!

Mit der Frage, die Sprache auch zur Laufzeit ändern zu können, hatte ich zunächst schnell die Rückmeldung bekommen, dass dies einfach mittels Sprachvariable "WWB_localize_n" möglich sei. Ein Test zeigte, dass das momentan nicht geht. Ein Studium des lua-Codes brachte Klarheit, warum das momentan so nicht geht.
Eine Funktion "WWB_change_language(n)" würde dieses Problem lösen. Dabei dürfen aber nur die Felder mit den mehrsprachigen Texten, z.B. ".description" übersetzt werden.

Was sich m.E. aber mit so einer Funktion nicht lösen lässt, sind die zur Laufzeit geänderten Texte. Ich kann zwar im Programm der description eines items über die Mehrsprachfunktion eine String in der aktuellen Sprache zuorden, diese nachtäglich geänderten Strings lassen sich aber über eine o.g. Funktion nicht nachträglich in die neue Sprache übersetzen. um solche Dinge müsste sich der Programmierer selbst kümmern. Sind das nicht so viele Elemente wäre es durchaus denkbar die zur-Laufzeit geänderten mehrsprachigen Strings in einer Tabelle zu speichern. Zusätzlich "WWB_change_language(n)" müsste man sich um die zur Laufzeit geänderten Strings selber kümmern.

Das Ganze ist ein "nice-to-have", es würde zu meinem gepanten WIG gut passen, denn da geht es um Partnerstädte, die in Frankreich, Italien und Ungarn liegen. Es wäre hier schön, man könnte die Infos zu den Städten auf Wunsch auch in der Landessprache lesen.

Muss aber nicht sein, die schon jetzt realisierte Mehrsprachigkeit ist weit mehr als ich je erwartet hatte.

docfred
 
B

bodenseepingu

Geomaster
Ich baue gerade eine englische Cartridge von megagrozilla um auf eine mehrsprachige Cartridge in Deutsch, Englisch, Französisch. Siehe hierzu http://www.geoclub.de/viewtopic.php?f=74&t=63276&start=10.

Für die Sprachumschaltung wie von dir gewünscht @docfred kannst du z.b. direkt die Funktion
get_translate_msg(nr, language) wie in dem Thread gepostet benutzen. Da holst du dir einfach zur
Laufzeit die Texte in der gewünschten Sprache per LUA benutzerdefiniertem Ausdruck...solltest du
normalerweise auch problemlos in Earwigo verwenden können - ich nehm ja an dass Earwigo auch ne Möglichkeit bietet, LUA-Code einzubetten...

Die Cartridge ist fast fertig - zumindest das Endresulat könnt ihr demnächst spielen (als Play-Anywhere oder wenn ihr wollt im Emulator). Da ich nicht der Source-Owner bin, kannich den Source-Code nicht veröffentlichen - außer von dem LUA-Teil wie im Thread bereits gemacht.
 
docfred

docfred

Geocacher
Das was du hier machst, war in EARWIGO seither überflüssig, WWB_localize("deutsch@@germann@@allemand") wählt den richtigen Teil in abh. von WWB_localize_n aus. Den mehrsprachigen String "deutsch@@germann@@allemand" kann man so direkt in der Web-Oberfläche pflegen, was das handling deutlich vereinfacht.

Das Problem sind nächträgliche Änderungen. Das ist in deiner Lösung einfacher, denn du kannst auch die gespeicheren Sprachstrings zur Laufzeit bearbeiten.
Beispiel
var_translations[1] =
{
descr = "There are ".. var_bottle_count.." bottles in the box",
descr_ger = "Es sind "..var_bottle_count.." Flaschen in der Kiste";
}

mit deiner Funktion: translate(cartridge, language)
kannst du dann auch ohne Sprachwechsel den neue Inhalt (für beide Sprachen) zuweisen.
Du musst allerdings die dynamischen bzw. geänderten Texte so handeln und kannst ihn nicht alleine über die Urwigo-drag-n-drop zuweisen.
docfred
 
S

sTeamTraen

Geocacher
sTeamTraen schrieb:
Wie DocFred entdeckt hat, geht das dynmaisches Umstellen der Sprache nicht so einfach. Ich bitte um geduld während die Bugfix-Procedure... :)
Zum Vergrößern anklicken....
Nach dem Update von heute, soll diese Funktionalität jetzt ungefähr laufen. :)
 
docfred

docfred

Geocacher
sTeamTraen schrieb:
sTeamTraen schrieb:
Wie DocFred entdeckt hat, geht das dynmaisches Umstellen der Sprache nicht so einfach. Ich bitte um geduld während die Bugfix-Procedure... :)
Zum Vergrößern anklicken....
Nach dem Update von heute, soll diese Funktionalität jetzt ungefähr laufen. :)
Zum Vergrößern anklicken....

Kurze Frage:
Mit WWB_localize_n =x doder mit WWB_change_language(x) ?

docfred

Habe es selbst rausgefunden: WWB_change_language(x)
DAS IST TOTAL ABGEFAHREN! Danke

Die Frage die noch bleibt wie verhält es sich mit den zur Laufzeit geänderten Strings?
 
docfred

docfred

Geocacher
Hab grad mal einer Item.description einen multilanguagestring zugewiesen

Wert setzen Gegenstand:Flasche:Beschreibung => Konstante:"Dies ist eine Flasche!@@This is a bottle@@C'est une bouteille!"

Der kommt jetzt aber im Gesamten:
Dies ist eine Flasche!@@This is a bottle@@C'est une bouteille!

docfred
 
S

sTeamTraen

Geocacher
sTeamTraen schrieb:
Upps. Du hast gleich, im string-Konstant wird kein Lokalisation gemacht. Bitte in Earwigo-Group als Bug melden.
Zum Vergrößern anklicken....
Aber... ist es wirklich ein Bug? Warum soll das Runtimesystem "eingreifen" nur bei der einfache Zuordnung eines Werts an einer Variabel? Wäre das nicht besser, WWB_localize(var_xxx) später zu tun?
 
docfred

docfred

Geocacher
Also momentan sehe ich das Problem, dass dies gar nichts mit der neuen Funktion "WWB_change_language()" zu tun hat. Wenn ich einen mehrsprachigen WIG programmiere muss ich doch dafür sorgen, dass eine Wertzuweisung in allen Sprachen erfolgt. Das hat noch gar nichts mit der Umschaltung zur Laufzeit zu tun, sondern ist auch notwendig, wenn ich die Sprachwahl nur beim Start der Cartidge mache.

function zitemFlaschebottlebouteille:OnTextzuweisenAssigntextchangelemot()
-- #GroupDescription=Script --
-- #Comment=Script Comment --
zitemFlaschebottlebouteille.Description =X "Dies ist eine Flasche!@@This is a bottle@@C'est une bouteille!"


X Hier fehlt m.E. "WWB_localize()", oder muss ich mich da zur Laufzeit selber drum kümmern?

docfred
 
S

sTeamTraen

Geocacher
Nach mehr Überlegung glaube ich dass Du richtig bist. Wenn man eine "statische" Sprachevariante macht (Compile-time language selection), wurden solche Strings doch lokalisiert. Es ist also logisch (oder mindestens "konsequent"), dass sie auch dynamisch lokalisiert wurden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben