Zusätzliche Sprache in Freetz

[knight20001]

Hallo an alle ich arbeite gerade an einer Französischen Übersetzungserweiterung für Freetz!

Ich hoffe, daß dies auch in Eurem Sinne ist.

Gruß
Knight20001

 

[hermann72pb]

Willst du es für alle Pakete machen oder nur für Hauptoberfläche? Bei den Paketen wird es nämlich aufwendig...

MfG

 

[bodega]

Das Beste wäre ja, wenn man einfach Sprachdateien hinterlegen könnte. Bei den einzelnen Paketen wäre das schon aufwendig, aber auch nicht unmöglich.

Franz. Sprache brauch ich zwar nicht unbedingt, aber Englisch wäre schon gut. Das verstehen auch viele.

 

[RalfFriedl]

Ich bin auch der Meinung, daß das derzeitige Sprach-Konzept nicht gut für mehrere Sprachen geeignet ist. Schon mit den beiden vorhandenen wird es unübersichtlich, wenn längere Texte verwendet werden. Wenn noch mehr Sprachen dazukommen, sollten wir dafür etwas neues suchen/entwickeln.

 

[olistudent]

Da muss ich Ralf zustimmen. Ich hätte nichts dagegen, wenn jemand Freetz auf französisch übersetzt, vorrausgesetzt es besteht der Bedarf dafür. Aber mit dem jetzigen Sprachkonzept ist das nicht möglich bzw. wird das sehr unübersichtlich.

MfG Oliver

 

[knight20001]

also derzeit mache ich mir schon die mühe, überall dort wo schon zweisprechig eingetragen ist auf dreisprachig zu ergänzen.

Ich hab schon gesehen, daß das sehr aufwendig wird, ist aber machbar.
Das einzigste Problem wird sein, daß ich das Datei für Datei einzeln machen muß.

Wenn wir natürlich das Sprachmodell in form von ner Art mysql-database verwirklichen könnten wäre das genial.
Nur glaube ich, daß das sich nicht verwirklichen lassen würde.
Das mit der sql-Geschichte ist nur so ein Gedankengang von mir, den man nicht so sehr Ernst nehmen sollte

Gruß

 

[olistudent]

Wir haben ja keine PHP-Seiten, da hab ich das auch schon gehört. Man müsste halt alle Sprachelemente durch Variablen ersetzen und dann abhängig von der gewählten Sprache die Variablen aus unterschiedlichen Dateien belegen. Wobei der Aufwand für sowas natürlich riesig ist.

MfG Oliver

 

[RalfFriedl]

Eine SQL-Datenbank bringt uns hier nicht weiter, das Problem ist janicht der Abruf der Texte, sondern die Erstellung und Änderung.

Was ich mir vorstellen könnte, ist ungefähr folgendes:
Es gibt jetzt schon die Dateien .language, in denen hauptsächlich die Dateien aufgelistet sind, in denen sprachabhängige Texte stehen.

Je nach Anzahl der Sprachen könnte man entweder hier zusätzlich die Texte in allen Sprachen unterbringen, oder für jede Sprache eine weitere Datei erstellen.

Bei einer überschaubaren Anzahl von Sprachen würde ich erstmal alle Sprachen in einer Datei lassen. Damit ist klar, daß wenn man einen Text einfügt, der in allen Sprachen eingefügt werden muß.

Wenn es wirklich viele Sprachen werden sollten, wird es irgendwann übersichtlicher, jede Sprache in einer eigenen Datei zu halten.

Sinnvollerweise sollte man auch überlegen, welche Werkzeuge dafür hilfreich wären, um sich die Arbeit zu vereinfachen.

 

[McNetic]

Also, wenn mich nicht alles täuscht, sind doch sowieso bereits jetzt alle Sprachelemente parametriesiert und mit diesen $lang()-Konstrukten versehen- bisher eben nur in zwei Sprachen. Das alles in eine Datenbank zu stecken, hat m.E. keinen Sinn. Die Übersetzung z.B. von einzelnen Paketen gehört nunmal zu den Paketen. Mein Vorschlag wäre so etwas wie folgendes:

• Die $(lang )-Konstrukte würden so ersetzt, daß dort nur mehr ein einzelner Text in der Default-Sprache (Englisch?) drin stände (Beispiel $(lang "Example")). Wenn wir trickreich werden wollen, erlauben wir noch zusätzlich Variablen im Text, à la $(lang "I met %name%.")[name:"Paula"], dann sind sprachliche Konstrukte in der Übersetzung besser zu handhaben (im Deutschen muss es ja "I habe %name% getroffen." heissen, also andere Satzstruktur).
• Die .language-Dateien blieben erhalten, wie sie sind.
• Zusätzlich würde es ein Verzeichnis .lang o.ä. geben, in dem dann jeweils Dateien für jede vorhandene Übersetzung liegen (de, en, fr, ...). Diese hätten dann ein Format ähnlich dem der gettext()-PO-Dateien. Sie wären aufgebaut aus solchen Konstrukten:
  

  #: dateiname
  msgid originaltext
  msgstr übersetzter text

• Wenn eine übersetzte Zeichenkette fehlt, kann man als Fallback das Original einbauen.

So eine Lösung wäre meines Erachtens noch relativ einfach zu implementieren. Ich denke, der komplette vorhandene Bestand liesse sich auch ohne größere Schwierigkeiten per Script anpassen. Vorteil der Lösung wäre auch, daß die Sprachdateien sich einfach per Skript anlegen und auf fehlende Teile und Sprachen testen lassen würden.

Ich wäre bereit und in der Lage, etwas ähnliches zu implementieren - nach meiner Klausur am 16.02. . Dazu bräuchten wir aber einen Konsens, und ich bin sicher, mein Lösungsansatz ist noch nicht vollständig/perfekt.

Gruss, Nico

EDIT: Da war RalfFriedl wohl etwas schneller. Sein Ansatz ist ja im Grunde genau der gleiche, bei mir ists schon etwas genauer spezifiziert.

 

[RalfFriedl]

Im Wesentlichen ist es daas Gleiche, außer daß ich im Moment es sinnvoller fände, alle Texte in einer Datei zu haben, wobei die Werkzeuge am Besten gleich mit beiden Varianten zurecht kommen sollten.

Die Konstruktion mit den Parametern hinten zu unterstützen wird etwas komplizierter und ist zum Glück nicht notwendig. Das Ergebnis eines $lang Konstrukts muß ein konstanter Text sein. Ich glaube nicht, daß wir uns den Overhead mit dynamischer Sprachumschaltung antun wollen.

Das Default-Sprache würde ich Deutsch nehmen. Einerseits ist es die Sprache, wie wohl von den meisten verwendet wird, zum anderen ist die Grammatik etwas ausgefeilter, so daß man nicht die Gefahr hat, daß zwei gleiche Wörter in Englisch in zwei verschiedene in Deutsch abgebildet werden müssen.

Das Auslesen der vorhandenen $lang Konstrukte sollte automatisch funktionieren, dies wird jetzt ja auch schon beim Erstellen der Firmware automatisch ausgewertet.

 

[Silent-Tears]

Wobei der Aufwand für sowas natürlich riesig ist.

Anfangs ja, denn jede der Dateien müsste angepackt und abgeändert werden.

Ich glaube nicht, daß wir uns den Overhead mit dynamischer Sprachumschaltung antun wollen.

Nein Ralf, da gebe ich dir Recht. Nicht, dass ein paar Textdateien wirklich ins Gewicht fallen würden im squashfs, aber der Rechenaufwand den die arme Box dann leisten muss ist eher unnötig.

Ähnliche wir hier vorgeschlagene Konstrukte bauen wir gerade in der Firma für unsere Softwares ein, von daher kann ich mir relativ gut vorstellen, wie das Ganze später passiert. Genannte Methoden sind so eigentlich auch ohne grossartige (nur zeitliche) Schwierigkeiten zu implentieren.

Vor allem aber würde wahrscheinlich der Quelltext der Dateien im Freetz besser wartbar.

LG

 

[knight20001]

ist schon interessant !

wir diskutieren hier das ganze schon mal aus, aber das aktuelle Umfrageergebnis ist anderer Meinung !

Wobei ich das schon weiter verfolgen möchte und mache.

Es gibt ja nicht nur Deutsche und Englishe User, sondern auch der französische Sprachraum ist sehr weit verbreitet.

Ich werde irgendwie nun das basteln und die Ansatzpunkte sehen sehr gut bisher aus. Wenn eine Einigkeit im Bezug auf das wie herrscht kann ich ja dahingehend modifizieren.

Auch wie das mit dem .patch - File geht habe ich nun raus und werde dies dann erst einmal so dann anbieten.

 

[McNetic]

Anfangs ja, denn jede der Dateien müsste angepackt und abgeändert werden.

Wie gesagt, ich denke diese Änderungen könnten ohne große Schwierigkeiten mit einem kleinen Script erledigt werden.

wir diskutieren hier das ganze schon mal aus, aber das aktuelle Umfrageergebnis ist anderer Meinung !

Das kommt wohl ganz auf die Lesart an. Wenn Du Dir überlegst, wie viele Leute dsmod/Freetz einsetzen, und Dir nicht die absolute Zahl anschaust, sondern den Prozentsatz, dann finde ich 15% schon ziemlich viel. Ich kann mir nicht vorstellen, daß 15% der Modder die englische Version benutzen (und die Zahl ist natürlich statistisch gesehen sowieso noch nicht sonderlich aussagekräftig).

 

[bodega]

Ich hätte mir das jetzt so vorgestellt:

lang_de.cgi:

export APPNAME_LANG_TITLE="Ein Titel für die Seite"
export APPNAME_LANG_INPUT1="Eingabefeld 1:"
export APPNAME_LANG_INPUT2="Eingabefeld 2:"

package.cgi:

if [ -f ./lang_de.cgi ]; then . ./lang_de.cgi; fi
if [ -f ./lang_en.cgi ]; then . ./lang_en.cgi; fi

# usw..
<html><head><title>$APPNAME_LANG_TITLE</title></head>
<body>
$APPNAME_LANG_INPUT1 <input name="field1" value="$APPNAME_VALUE1"><br>
$APPNAME_LANG_INPUT2 <input name="field2" value="$APPNAME_VALUE2"><br>
</body>
</html>

Der Overhead durch das Laden, würde geringfügig mehr werden.

 

[knight20001]

Das sieht doch gut aus, aber warum alles mit reinpacken ?

Das soll beim Imageerstellen ausgewählt werden, und dann kommt nur die Sprache rein welche ausgewählt wurde.
Unnötig aufblähen müssen wir das ganze doch nicht.

Somit würde auch die Ladezeit sich nicht verändern oder ?

 

[bodega]

Muss man nicht unbedingt. Falls die Datei nicht gefunden wird, wird die Sprache nicht geladen. Man könnte also auch 'lang_en.cgi' weglassen. Die Konstanten müssen nur in beiden Sprachdateien gleich lauten.

Die Ladezeiten werden bei 5 bis 10 Einträgen nicht soo drastisch steigen. Man wird es wahrscheinlich nicht mal merken.

 

[ramik]

I also vote from international languages of the freetz, not just germans and english, i will be really interested in Italian and i will be glad to do it too in case some framework is done for i18n

 

[McNetic]

Ich hätte mir das jetzt so vorgestellt:
[...]
Der Overhead durch das Laden, würde geringfügig mehr werden.

Du gehst davon aus, daß die Übersetzungen sich nur in cgis bzw. nur in Shell-Scripten befinden. Das ist aber gar nicht unbedingt der Fall.

Gruss, Nico

 

[bodega]

Klar. Es wurde ja nur vom WebIf und den Paketen gesprochen. Was willst du denn noch übersetzen?

 

[McNetic]

Ich will gar nix übersetzen . Aber es war ja die Rede davon, das Language-Framework zu ersetzen, und das ist momentan völlig unabhängig vom Inhalt der Dateien. Ich weiss nicht, ob manche Pakete evtl. auch normale Scripte übersetzen oder was auch immer - es ist aber jedenfalls möglich.

EDIT: Es gibt tatsächlich Packages, die 'normale' Shell scripts übersetzen.