| 

.NET C# Java Javascript Exception

Re: Namensvorschlag für ein alternatives localizations-plugin ?

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


Re: Namensvorschlag für ein alternatives localizations-plugin ?

koeberle - 27.10.2010 08:55
Seit wann sind den keine Ziffern erlaubt? Es gibt doch schließlich das I18n Templates Plugin.

Christian


Re: Namensvorschlag für ein alternatives localizations-plugin ?

milkyman - 27.10.2010 09:36
Oha, im Namen ausdenken bin ich ganz mies. :-(
Mir fiel höchstens sowas wie db-localization / db-locale / locale-in-db ein.


Aber der christian kann das ganz gut, der hat sich auch die glossy-templates ausgedacht. :-)

Bye,
Horst


Re: Namensvorschlag für ein alternatives localizations-plugin ?

koeberle - 27.10.2010 09:40
Worin liegt eigentlich der Vorteil für i18n dies mit einer Datenbank zu steuern als es mit properties-Datein zu regeln?

Christian


Re: Namensvorschlag für ein alternatives localizations-plugin ?

slyfox1972 - 27.10.2010 11:00
koeberle schrieb:
-------------------------------------------------------
> Worin liegt eigentlich der Vorteil für i18n dies
> mit einer Datenbank zu steuern als es mit
> properties-Datein zu regeln?

properties-Dateien sind Quellcode. Möchte man darin was ändern, z.B. Texte korrigieren, neue Sprachen hinzufügen, muss mal den Quellcode ändern, und die App neu installieren.
Da ist es über Datenbank besser, und mittels einer Tabellendarstellung auch übersichtlicher und bequemer.

Nachteil:
Kein create-drop mehr möglich (möglich schon noch, aber der die Texte werden stets gelöscht), und man muss die Texte ständig als ASCII sichern. Deswegen ein Script,welches das erledigt.

Grüße

Egon Schmid


Re: Namensvorschlag für ein alternatives localizations-plugin ?

badbadverybad - 29.10.2010 20:02
slyfox1972 schrieb:
-------------------------------------------------------
> koeberle schrieb:
> --------------------------------------------------
> -----
> > Worin liegt eigentlich der Vorteil für i18n
> dies
> > mit einer Datenbank zu steuern als es mit
> > properties-Datein zu regeln?
>
> properties-Dateien sind Quellcode. Möchte man
> darin was ändern, z.B. Texte korrigieren, neue
> Sprachen hinzufügen, muss mal den Quellcode
> ändern, und die App neu installieren.

Falsch.

Füge einfach folgenden Schnipsel in die scripts/Events.groovy-Datei des Projekts ein, dann werden die i18n-Properties-Dateien beim Build unverändert kopiert (und natürlich von der Anwendung ausgewertet):
Language: Groovy
eventCompileEnd = { ant.copy(todir:classesDirPath) { fileset(file:"${basedir}/grails-app/i18n/*.properties") } }
Es ist ein typischer Anfängerfehler in der Softwareentwicklung, Lösungen zu erstellen, bevor das Problem und sein Kontext analysiert worden ist. - Kostet die IT-Firmen im Durchschnitt bestimmt ein Viertel ihrer Marge. ;-)


Re: Namensvorschlag für ein alternatives localizations-plugin ?

koeberle - 01.11.2010 09:17
So etwas habe ich geahnt. Und wenn das so ist, bringt das Plugin null zusätzlichen Nutzen. So ein Plugin wird erst sinnvoll wenn es der Nutzer der Anwendung auch anpassen kann, ohne zu wissen wie die Properies heißen. Und da bist du schon auf dem halben Weg zu einem CRM.
Christian


Re: Namensvorschlag für ein alternatives localizations-plugin ?

milkyman - 02.11.2010 07:32
Moin moin.

Ich glaub ich steh hier etwas auf dem Schlauch.

Auch der Code-Schnipsel ändert doch nichts dran, dass ich neu deployen muss, wenn es Textänderungen in den Properties gibt?

Und gerade das zu vermeiden erscheint mir der große Vorteil der DB-Variante. Von daher halte ich die schon für sinnvoll.

Bye,
Horst


ReloadableResourceBundleMessageSource

badbadverybad - 02.11.2010 15:55
milkyman schrieb:
-------------------------------------------------------
> Moin moin.
>
> Ich glaub ich steh hier etwas auf dem Schlauch.
>
> Auch der Code-Schnipsel ändert doch nichts dran,
> dass ich neu deployen muss, wenn es Textänderungen
> in den Properties gibt?

Ja, aber wenigstens nicht kompilieren, oder den Server neu starten.

Es geht aber noch besser: Um die .properties-Dateien nach einer bestimmten Zeit neu zu laden, läßt sich eine ReloadableResourceBundleMessageSource konfigurieren, wie hier beschrieben (zusätzlich noch cacheSeconds setzen).

Und da bei der ReloadableResourceBundleMessageSource auch nur mit Wasser gekocht wird, lassen sich mit einer eigenen Implementierung auch andere Strategien umsetzen, z.B. "Neuladen nach Setzen eines Parameters in der Admin-Oberfläche".

Das ist, warum modulare und transparente Frameworks - wie Spring (und teilweise Grails) - so viel Spaß machen! Man kann sie aufbohren ohne Ende.

> Und gerade das zu vermeiden erscheint mir der
> große Vorteil der DB-Variante. Von daher halte ich
> die schon für sinnvoll.

Die Framework-Leute haben sich schon was dabei gedacht, wie sie mit i18n-Sachen umgehen. Und diese Lösungen lassen sich weiter konfigurieren oder sogar erweitern, anstatt dick und fett daran vorbeizubauen.

- Übrigens, Hibernate 3 legt neue MySQL 5-InnoDB-Tabellen mit LATIN-1-Zeichensatz an - da hätten wir schon mal ein Problem bei der Datenbanklösung. (Auch hier läßt sich der ensprechende Hibernate-Dialekt schön überschreiben und aufbohren, aber dann brauchen wir einen Workaround für die Endnutzer-Konfiguration.)


Re: ReloadableResourceBundleMessageSource

badbadverybad - 02.11.2010 18:41
milkyman schrieb:
-------------------------------------------------------

Was Du schreibst, ist - ganz untypisch für einen Programmierer übrigens - etwas unscharf.

> Ok, das mit dem Zeichensatz ist so eine Sache.
> Aber die kann man einmalig lösen.

Welche Probleme würdest Du denn mehrmalig lösen?! - Wenn ein Grails-Plugin installiert (und womöglich noch konfiguriert) ist, sollten doch wohl alle Probleme, die das Plugin adressiert, abgeschlossen sein, oder?

> Es bleibt aber, dass die Anwendung einfach
> weiterläuft und neue Texte ziehen kann,

Auch bei einer Datenbank-Lösung sollten I18n-Strings zwischengespeichert (gecacht) werden. Sonst hätte man ja z.B. beim Aufruf einer View ruckzuck ein oder zwei dutzend Datenbank-Abfragen.

> während
> alle Datei-basierten Lösungen einen Reload der
> Anwendung

Nein, die ReloadableResourceBundleMessageSource speichert, wie schon beschrieben, die I18n-Strings (oder andere Messages) für einen angegebenen Zeitraum zwischen, bevor sie (nicht die Anwendung) neugeladen werden. (Nochmal schreibe ich's aber nicht!)

> oder aber externe Dateien erfordern.

Das haben Datei-basierte Lösung so an sich. - Übrigens ist es viel einfacher, einen String in einer Textdatei zu ändern als in einer Datenbank-Tabelle.

> Diese Art der Lösung scheint mir wesentlich
> fehleranfälliger zu sein.

Beweis durch Anschein? - Was soll daran überhaupt fehleranfällig sein? Es sind ja gerademal zehn Zeilen Config involviert. - Übrigens ist dies die zentrale Standard-Methode im Spring-Framework, mit i18n-Strings umzugehen, und wird entsprechend auch im Grails User Guide behandelt.

> Wobei ich zugeben muss,
> sowas auch schon gemacht zu haben. ;-)

Traue ich Dir, ehrlich gesagt, gar nicht zu. ;-)


Re: ReloadableResourceBundleMessageSource

saurier - 03.11.2010 12:21
Hallo Horst,

Zitat

Es zieht sich wie ein roter Faden durch, wir betrachten die Dinge aus verschiedenen Blickwinkeln.

Ein Phänomen, dem man in der Softwareentwicklung nicht selten begegnet :-)

Aber zur Sache: Ich kenne auch Anwendungen, bei denen die Internationalisierung über die Datenbank
gemacht wird - und das aus guten Gründen. Bei großen Anwendungen werden ja oft externe Übersetzer,
oder auch Agenturen mit der Übersetzung beauftragt. Die brauchen aber nicht nur den zu übersetzenden
Text, sondern auch noch den entsprechenden Kontext, weitere Erklärungen, oder auch Angaben zur
erlaubten Länge der Übersetzung. Da ist es einfach nicht mehr praktikabel, mit Properies-Dateien
zu hantieren. Wie du schon sagtest, die bekommen eine Web-Oberfläche in der sie ihre Übersetzungen
machen, und diese auch noch Kommentieren können.

Gruß,
Christian


Re: ReloadableResourceBundleMessageSource

badbadverybad - 05.11.2010 01:24
saurier schrieb:
-------------------------------------------------------
> Da ist es
> einfach nicht mehr praktikabel, mit
> Properies-Dateien
> zu hantieren. Wie du schon sagtest, die [Übersetzer] bekommen
> eine Web-Oberfläche in der sie ihre Übersetzungen
> machen, und diese auch noch Kommentieren können.

Solche Übersetzer arbeiten aber nicht auf der Endanwendung, sondern bekommen eine eigene Übersetzungs-Anwendung (Stichworte: "Across", "Translation Memory", usw.). Die funktioniert nochmal ganz anders, und der Austausch erfolgt meistens standardisiert über PO-Dateien.

Die Ergebnisse werden in die Endanwendung nur eingebracht (nichts weiter), und da spielt es rein gar keine Rolle, wie die Texte übersetzt worden waren.

- Das sind unterschiedliche Anwendungen.


Re: ReloadableResourceBundleMessageSource

saurier - 05.11.2010 12:34
<_42_4c_4f_43_4b_51_55_4f_54_45_ CLASS="bbcode"><_44_49_56_><_53_4d_41_4c_4c_>Zitat<_42_52_ /><_53_54_52_4f_4e_47_><_42_52_ /> Solche Übersetzer arbeiten aber nicht auf der Endanwendung... <_42_52_ /> In den Anwendungen die ich kenne, arbeiten die Übersetzer durchaus direkt auf der Endanwendung. Das sind <_42_52_ /> im Grunde einfach ein paar Views, die nur für die Übersetzer da sind. Wenn die ihre Arbeit erledigt haben, werden <_42_52_ /> die Texte nochmal geprüft und dann freigeschaltet. <_42_52_ /> Was du beschreibst, ist ein übliches Verfahren für Software die mehrfach verteilt wird. Für große individuelle <_42_52_ /> Server-Anwendungen kann man sich das Hantieren mit PO-Dateien aber sparen. <_42_52_ /> <_42_52_ /> Gruß, <_42_52_ /> Christian


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "Re: Namensvorschlag für ein alternatives localizations-plugin ?" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.