Re: Erfahrungswerte für Vorgehen bei Lokalisierung

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hallo Holger,

ich quote mal voll.

Holger Vorberg schrieb:
wir wollen (müssen) unsere ASP.NET Anwendung mehrsprachig machen. Das war von Anfang an vorgesehen, aber es bestand bis jetzt eigentlich kein wirkliches Konzept dafür. Der aktuelle Stand ist deshalb, dass wir ca. 150 Forms haben, in denen sämtliche Strings "hardcodiert" sind, und entweder als .Text, .Tooltip oder ähnlichen Eigenschaften zugeordnet sind, oder sie werden im Codebehind (C#) zugewiesen.

Wir haben uns entschlossen, die von .NET vorgesehene Variante der Lokalisierung über Resource Dateien zu verwenden (es stand auch im Raum, alles über eine String Tabelle der DB zu machen, was aber verworfen wurde).

Leider ist es mit dem Treffen dieser Entscheidung allein ja nicht getan. Bevor wir anfangen, irgendwelche Wörter oder Texte in eine andere Sprache zu übersetzen, müssen wir erstmal dafür sorgen, dass wir sämtliche Strings in deutschen Resource Dateien haben.

Wir sind z.Zt. mit 4 Entwicklern tätig, wobei jeder seinen eigenen Bereich hat. Manchmal gibts es Überschneidungen, aber das ist ja normal.

Der Punkt ist, dass es nun unterschiedliche Meinungen darüber gibt, ob wir sämtliche Strings in einer einzigen globalen Resource Datei speichern, oder ob wir die Resourcen "verteilen". Damit ist gemeint, dass z.B. Strings, die überall bzw. an mehreren Stellen verwendet werden, in eine globale Resource Datei wandern, aber bestimmte Strings, die voraussichtlich nur in einem bestimmten Bereich benötigt werden, auf Formular- oder Usercontrolebene in separaten Resourcedateien gehalten werden.

Hat da jemand Erfahrung, was sich besser handhaben lässt?

Ein Argument gegen die Verwendung einer einzigen Resourcedatei wäre z.B., dass es nicht möglich ist, dass nun alle Entwickler gleichzeitig ihre Formulare von hardcodierten Strings bereinigen, weil wir uns dann ständig gegenseitig diese Resourcedatei sperren und immer der eine auf den anderen warten muss. In diesem Fall wäre einer dazu "verdammt" diese Strings aus allen Formularen herauszuziehen, was dann zwar die Resourcedatei besser handhabbar machen würde, aber das Problem des Sperrens immer noch bei den eigentlichen Formularen bestünde.

Bin für jede Meinung dankbar!

Letztendlich läuft alles darauf hinaus, was das praktikabelste
für den Übersetzungs-Workflow ist. Ob ihr nun alle gemeinsam
die 150 Seiten bearbeitet oder einer nach dem anderen spielt da
eigentlich ne untergeordnete Rolle, weil man das einmalig schon
handhaben kann.

Viel wichtiger ist dann aber: wie kommen die Daten aus der .resx
zum Übersetzer, und noch wichtiger: wie wieder zurück? Ich kenne
kein Übersetzungsbüro, denen man die Dateien so hinwerfen kann,
bzw. eins was z.B. mit dem Zeta-Resourcen-Editor arbeitet, die
wollen meist Excel.

Also musst du ein Tool schreiben (ggf. gibt's inzwischen schon
was) womit du im- und exportieren kannst.

Womit wir bei der Frage wären, ob eine große .resx oder viele
lokale - ich denke weder der Übersetzer noch du/deine Kollegen
dürften sich über 150-Excel-Dateien und damit 300-Im- und Export-
Aktionen freuen.

Was gegen eine Datei spricht: "schnelle Änderungen" werden zur
Tortur, darüber hinaus benötigt ihr absolut eindeutige Keys,
zweimal Label1.Tooltip funktioniert dort halt nicht. Und wie
sich eine am Ende mehrere Megabyte große .resx in der Praxis
macht weiß ich auch nicht, könnte mir aber vorstellen, dass
es da den einen oder anderen Hänger gibt.

Meine Meinung: ich würde nochmal über eine Datenbanklösung
nachdenken. Die Performance dürfte da ja eher keine Rolle
spielen, ggf. cacht ihr dann. Ihr seid aber so mit der
Datenhaltung und vor allem auch dem Im- und export wesentlich
flexibler, im einfachsten Fall generierst du ein Excelsheet
für den Übersetzer einfach via Management Studio > Export.

--
Gruß, Thomas [MVP ASP/ASP.NET]
http://blog.thomasbandt.de - Blog
http://www.69grad.de - ASP.NET, Webdesign und mehr.
.

Relevant Pages

  • Re: Visual C++ 6 support issue
    ... >> A common IDE is a good idea, but usually in programming, you have ... >would do what made sense for that language. ... >or at least for allocating resource ID values within specified ranges. ... >That is, for example, I'd like to keep all the help strings and all the ...
    (microsoft.public.vc.mfc)
  • Re: Multilanguage application
    ... these strings are stored as resources in system DLLs. ... if you open comctl32.dll in any resource editor (for example Resource ... "Mike Shkolnik" wrote in message ... >> either using TsiLang's implementations of these functions or translate ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: messabebox(...) v afxmessanebox
    ... I was just wondering why you would store MFC resources in vectors when the resource file concept is so handy. ... Maybe you only have "strings" to deal with and not dialogs, icons, bitmaps, toolbars, menus, and strings. ... "Roger Rabbit" wrote in message ...
    (microsoft.public.vc.mfc)
  • =?iso-8859-1?Q?Erfahrungswerte_f=FCr_Vorgehen_bei_Lokalisierung?=
    ... Das war von Anfang an vorgesehen, aber es bestand bis jetzt eigentlich kein wirkliches Konzept dafür. ... Wir haben uns entschlossen, die von .NET vorgesehene Variante der Lokalisierung über Resource Dateien zu verwenden. ... In diesem Fall wäre einer dazu "verdammt" diese Strings aus allen Formularen herauszuziehen, was dann zwar die Resourcedatei besser handhabbar machen würde, aber das Problem des Sperrens immer noch bei den eigentlichen Formularen bestünde. ...
    (microsoft.public.de.german.entwickler.dotnet.asp)
  • Re: Tools zur Lokalisierung ASP.NET 2.0
    ... > Es ist zwar nett aus dem Visual Studio für eine Seite die Resource ... Aber irgendwie werden es doch schnell viele Dateien ... Microsoft MVP - Visual Developer ASP/ASP.NET ... Next by Date: ...
    (microsoft.public.de.german.entwickler.dotnet.asp)