Mozilla Update lokalisieren

    Sorry mein fehler. Hab mich schon gewundert, dass der Bug nicht vorhanden ist. Hab mich wohl vertippt. :(
    Krank sein / für Prüfungen lernen und mich mit FF beschäftigen ist wohl ein wenig viel für mein Hirn :-/

    Nachdem das ja alles PHP-Scripte sind sollte es ja nicht soo komplizieret sein das Ding zu lokalisieren. Man müsste ja nur jedes print() suchen und durch ein einsprechendes locPrint("Stadanrdtext", "kürzel") ersetzen und dann alle kürzel übersetzen, oder ein print(string, string) ableiten, oder was weiß ich. hab von Localisierung nicht so viel ahnung, würd aber mithelfen sobald meine Prüfungen endlich rum sind.... (Ab nächstem Wochenende)

    Wie Wolf im bug geschrieben hat, muss u.m.o erst einmal lokalisierbar gemacht werden, d.h. das die Strings in getrennten Dateien liegen etc.
    Das komplette Skript bei jeder Änderung durchzugehen macht keinen Sinn.

    Nochmal zur Verdeutlichung: erst u.m.o komplett umschreiben, dann anfangen zu Übersetzen. Eine Heidenarbeit :(

    Viele Grüße . . . Martin


    In a world without walls and fences, who needs windows and gates?
    - - -
    Kein Support per PN oder email!

    Das ist mir schon klar. Ich bin nur ein fan von irgendwas hardgecodetem. Englischer Text im code, Localisationen in externen Datein. So vermeidet, dass bei einem Fehler, welcher art auch immer, gar kein Text da steht.

    Weil das umschreibe aufwändig ist hab ich ja meine Hilfe angeboten. Im Prinzip ist das je keine großartig geistige Arbeit sondern haupsächlich, erstzen, der prints durch eine funktion die dann je nach lokalisation die variablen auflöst...

    Zitat von morty

    Ich bin nur ein fan von irgendwas hardgecodetem.


    Genau dagegen kämpfen alle Übersetzer immer. Lokalisierbarkeit bedeutet nun mal, alles über Variablen zu machen.
    Das erleichtert nebenbei dann auch die Pflege des englischen Textes.

    Wie auch immer, ich weiß nicht wie u.m.o strukturiert ist und habe auch selber keine Zeit momentan mich der Sache anzunehmen. Schade wäre es allerdings schon, wenn es vor 1.0 nichts werden würde.

    Viele Grüße . . . Martin


    In a world without walls and fences, who needs windows and gates?
    - - -
    Kein Support per PN oder email!

    Wie man's macht ist mir wurscht. Ich hab auch nicht genug erfahrung, als das ich mir das zutrauen würde. (Hab zwar schon einiges programmiert, aber noch nichts richtig großes....) Wenn mir aber jemand sagt: Erstze alle print() durch printloc("var") und trage var="englischer String"; in die datei xy.eng ein, dann mach ich das. - Mehr wollte ich gar nicht!
    :)

    ok, ich werde Wolf mal drauf ansprechen wenn ich ihn im IRC sehe.
    Wenn wir das allerdings durchziehen wollen, brauchen wir einige Leute die sich mit php gut auskennen. Da würde ich mich z.B. nicht dazuzählen.
    Koordinieren würde ich eine solche Aktion allerdings, wenn es denn machbar ist. (wie gesagt - ich frag Wolf mal)

    Bis dahin könnten sich hier schonmal Freiwillige melden ;)

    Viele Grüße . . . Martin


    In a world without walls and fences, who needs windows and gates?
    - - -
    Kein Support per PN oder email!

    Ok, vieleicht sollte man das von Grund auf neu schreiben :) Der code ist wiklich alles andere als schön. Und besonders performant ist er auch nicht. Und insgesammt bietet es sich ja wirklich an das ganze objektorientiert zu machen.....

    Ansichtssache. Sicher kann etwas mit OO nie so performant bekommen wie wenn man classisch programmiert. Das setzt aber voraus das man gut programmiert und die übersicht behält.

    Naja man bräuchte halt mal jemanden der wirklich Ahnung hat.

    In 99% der Fälle ist die OO-Programmierung bei PHP nur praktisch für den Programmierer, niemals performant. Der einfachste Weg zum Ziel ist der schnellste und beste. Daher sollten solche Seiten laufzeitorientiert und nicht objektorientiert sein, mit möglichst wenig Verzweigungen. Das dadurch natürlich die "Erweiterbarkeit" leidet ist klar. Da wäre die OO-Programmierung im Vorteil. Aber wenn das System von vorneherein mit klaren Vorgaben programmiert wäre, dann muss es anschliessent auch nichtmehr gross erweitert werden.

    Bei solchen Seiten sollten die Script-Wege minimiert werden, übersichtsseiten am besten adminseitig immer statisch erstellt und nur verändert werden, wenn es mal zu änderungen kommt. würde vor allem die Last bei relaese-Tagen mindern. Zumal update.mozilla.org nie wirklich sehr schnell war.