Mehr als nur ASCII - Umlaute - UTF 8 - Sonderzeichen

[-Waldmeister-]

Ich möchte einen Wherigo in andere Sprachen übersetzen und bin dabei auf einiges Interessantes gestoßen:

1. Deutsche Umlaute
Deutsche Umlaute können auf allen meinen Playern:

• -OpenWIG r428 (Nokia N8)
  -DesktopWIG (Mac OS X 10.6.8 und Windows 8)
  -WhereYouGo (Android 4.0)
  -Wherigo (Ipod Touch 2G) v317
  -Garmin Oregon 450

durch die Kodierung string.char(228,246,252,223) (=äöüß) dargestellt werden.
Die hier erwähnten Unterschiede kann ich nicht feststellen:

Du hast gleich. Colorado/Oregon = WIN-1252 (fast ISO-8859-1 aber mit noch ein Paar karakter dabei). PocketPC/Emulator = UTF-8. WhereYouGo (Android)/DesktopWiG = ungefähr UTF-8, aber mit speziellen Java-Unicode-bugs. iPhone = ungefähr UTF-8, aber mit (anderen) speziellen Java-Unicode-bugs.

2. Sonderzeichen mit Absturz
2.1.
Manchen Sonderzeichen können in Urwigo erst gar nicht kompiliert werden wenn sie in einer Variable stehen.
zB ąĆćꣳńÓ󌜏źŻż (polnische Sonderzeichen):
satz=string.char(261,262,263,281,321,322,324,211,243,346,347,377,378,379,380)
(Für die einfache Übersetzung der Sonderzeichen habe ich mir ein kleines Java-Programm geschrieben)

2.2.
Umgeht man das ganze (durch dynamisches ersetzen der Zahlen oder durch direktes einsetzen in eine Nachricht) kommt es erst beim Aufruf im Emulator in Urwigo zu einem Fehler (Bad argument #1 to 'char').
Auch beim Garmin gibt es beim Aufruf einen Fehler.
Bei allen anderen Playern wird das richtige Sonderzeichen angezeigt.

3. Sonderzeichen im Array
Escaped man die Sonderzeichen (zb mit ##____; wobei ___ für die Zahl steht) kann man seine Übersetzungen schön in ein Array / eine Variable schreiben. (Um zB auf Krolocks Tutorial aufzubauen.)
MIt so einer Funktion könnte man sie dann während der Laufzeit zurückübersetzen:

function encode_utf8(s)
	for w in string.gfind(s, "##%d+;") do --sucht die Folge ##____; 
		for w2 in string.gfind(w "%d+") do --filtert die Zahl - muss keine forschleife sein
		s = string.gsub(s, "##"..w2..";", string.char(w2)) --ersetzt die sequenz
		end
	end
	return s
end

der Aufruf (für die obigen Sonderzeichen) wäre dann:
encode_utf8("##261;##262;##263;##281;##321;##322;##324;##211;##243;##346;##347;##377;##378;##379;##380;")

-Funktioniert auf fast allen Playern
-Der Android Player zeigt hier nichts an?! -> Obwohl die Sonderzeichen gehen
-Der Garmin wirft einen Fehler jedoch wegen den Sonderzeichen nicht wegen der Funktion (getestet)


4. Sonderzeichen ohne Absturz
Da 3. nicht zuverlässig funktioniert braucht man eine Methode, um herauszufinden ob der Player das kann.
Hier ist mir nur Try und Catch eingefallen.
Mit der Funktion pcall könnte man alle Sonderzeichen während der Laufzeit testen und den Fehler abfangen und behandeln.
-> Leider kann das der Iphone Player nicht -.- (sonst ALLE unter 1 erwähnten)

function getText(value) 			--Player fordert Übersetzung an 
status, err= pcall(encode_utf8,value)      --pcall ruft die funktion encode_utf8 mit den werten in value auf
							        -- pcall gibt den Status zurück (true, false) obs geklappt hat
							        --err = die Fehlermeldung im Fehlerfall
if status == true then
	return encode_utf8(value)
else 
	return "not available"
end
end

5. Lösungsversuch
Durch die "DeviceID" und/oder "Platform" könnte man versuchen die Player zu unterscheiden um nur manchen Playern eine bestimmte Sprache anzubieten

6. Ich freu mich über Lösungsvorschläge und/oder Ideen

 

[Charlenni]

1. Nun ja, dass Du keine Unterschiede feststellen konntest, ist nicht weiter verwunderlich. Die deutschen Umlaute liegen bei UTF-8 und Win-1252 an der gleichen Stelle. Allerdings gibt es ja noch weitere Sonderzeichen. Und die liegen nun mal bei UTF-8 und Win-1252 an verschiedenen Stellen.

2.1 In Lua sind char ein Byte lang, strings werden grundsätzlich aus Bytes zusammen gesetzt. Und Werte über 255 führen da natürlich zu Problemen. Deshalb dürfte string.char(211) schon funktionieren, aber string.char(261) zu Problemen führen.

2.2 Dass es bei den anderen Playern klappt, liegt auch daran. Dort werden 2 Bytes (261 = 1*256 + 5) übergeben und diese bilden daraus das UTF-8 Zeichen (in dem Fall nicht sichtbar, da string.char(1,5)) nicht sichtbare Zeichen sind.

3. Sonderzeichen kannst Du einfach mit "\Zeichencode" machen, also wäre das erste Zeichen in Deinem String in Unicode 261 (Hex U+0105) in UTF-8 als "\196\133" zu erreichen. Wäre dann mit string.char(50309) erreichbar, wegen 196*256+133=50309. Die aufwendige Ersetztenfunktion ist damit nicht nötig. Damit ist auch klar, warum der Android-Player nichts anzeigt: er kann kein Unicode, sondern nur UTF-8 (siehe dazu auch die Unicode-Tabelle unter http://www.utf8-zeichentabelle.de/unicode-utf8-table.pl?start=256&utf8=dec).

4. Wenn eine Funktion auf einem Player nicht funktioniert, dann muss man drum herum arbeiten. Immer aufwendig. Die Idee, um den Fehler abzufangen ist aber interessant. Wieder was gelernt

5. Im Prinzip so machen wie Earwigo. Am Besten alle Sonderzeichen in UTF-8 beim Erstellen hinterlegen, da das die meisten Player verstehen. Dann auf Garmin Playern die "\Code" herausfiltern und wenn möglich durch Win-1252 Zeichen ersetzten und alle anderen in ein "?" umsetzten.

6. Äh, hier könnte ein Hinweis auf Earwigo stehen, der das für dich übernimmt.

Sehr schön, dass es immer etwas Neues gibt. Vielen Dank. Das zeigt mir, dass Wherigo doch noch nicht tot ist.

 

[-Waldmeister-]

Vielen Dank für Deine Antwort und die Infos!
Bei 1. gings damals nur um Deutsche Umlaute deswegen war ich etwas verwundert.
Mit dem Hinterlegen und dem Aufruf der Sonderzeichen muss ich mich noch genauer beschäftigen. Sonderzeichen funktionieren bei Earwigo wirklich gut! Jedoch habe ich den ganzen Wherigo bereits in Urwigo geschrieben und möchte jetzt nicht umziehen