Tach!
Es ist sehr wohl sinnvoll, auch in neu zu schreibenden Programmen, Kürzel wie DEU und ENU oder Werte wie 0x0407 und 0x0409 zu verwenden, wenn der Anwendungsfall ist, mit Systemen zusammenzuarbeiten, die diese Kürzel/Werte bereits verwenden. Ich sehe es eher als nicht sinnvoll an, in solch einem Fall auf (anderen) Standards zu bestehen und dann im Programm sowie gedanklich ständig zwischen den Systemen hin- und herzukonvertieren, solange sich die Notwendigkeit der Verwendung dieses Standards nicht aus Aspekten des Anwendungsfalls selbst ergibt.
Es scheint ein beliebtes Spiel von dir zu werden, dir zu allem, was ich allegemeingültig nenne, ein Gegenbeispiel auszudenken. Nur ist das desöfteren nicht bis zu Ende gedacht.
Es scheint ein beliebtes Spiel zu sein, dass du dir Dinge als allgemeingültig ausmalst, die so aber nicht sind. Zudem denke ich mir das nicht aus, sondern erlebe sie in der Form in der Praxis. Und es ist mir auch klar, dass du das nicht bis zu Ende denken kannst, weil dir die Fakten dazu fehlen.
Die Notwendigkeit der Verwendung der standardisierten Sprachkennzeichnungen ergibt sich hier (wir reden von einer Webanwendung, nicht wahr?) aus Aspekten des Anwendungsfalls selbst. Die Sprachkennzeichnungen
de
,en-US
usw. sind erforderlich für die Angabe imlang
-Attribut.
Nein, wir reden nicht von einer Webanwendung. Deine Argumentation war ja allgemeingültig, nicht aufs Web beschränkt. In diesem Beispiel bezog ich mich auf Dynamics NAV, ein sogenanntes ERP-System. Hat auch im Laufe seiner Entwicklung einen Webclient spendiert bekommen, der spielt aber eigentlich keine große Rolle (bei den Anwendern, die ich kenne). Die meisten Anwender nehmen das Desktop-Programm. Wenn er jedoch eingesetzt wird, ist es firmenintern und kein öffentlicher Crawler oder Besucher hat diesen Intranet-Seiten einen Besuch abzustatten. Selbst wenn ein Admin so leichtfertig ist, der ERP-Anwendung uneingeschränkten Internetzugang zu gewähren, kommt der normale Besucher/Crawler nicht weiter als bis zur Anmeldeseite. Der Anwenderkreis ist genau vorherbestimmt und auch durch die Anzahl der erworbenen Lizenzen eingeschränkt. Also ist es auch egal, ob da für das Web standardisierte lang-Attribute vorhanden sind oder nicht. Lediglich die Mitarbeiter müssen damit umgehen können. Die Sprache für den Anwender wird traditionell über einen Dialog in der Anwendung eingestellt. Da muss der Webclient auch keine Extrawurst mit Language-Negotiation kochen für einen unscheinbaren Komfortvorteil. Es geht ja nicht darum, möglichst viele Besucher anzulocken, sondern die Mitarbeiter müssen ihre Arbeit erledigen können. Und das ist hier vollumfänglich gegeben durch die Spracheinstellung in der Anwendung.
In dem Fall würde ich anwendungsintern die standardisierten Sprachkennzeichnungen verwenden – das gibt besser lesbaren Code. Die Umwandlung in anderswo verwendete Kürzel/Werte erfolgt bei der Übergabe an jene Teile der Anwendung, wo die anderen Kürzel/Werte verwendet werden. Kontextwechsel – genau dann, wenn nötig, nicht früher.
Wenn nötig. Das ist der Punkt, an dem du dir eine andere Meinung bildest, obwohl du das System nicht kennst. Nötig ist es erst dann, wenn man zum Beispiel eine öffentlich erreichbare Website erstellen möchte, die auf die Daten des ERP-Systems zugreift, beispielsweise einen Shop. Erst dann beim Übergang zu diesem Shop ist es nötig, eine Übersetzung der Kürzel vorzunehmen. Vielleicht auch erst, wenn man die View erstellt. Das zu beurteilen hängt vom Shop ab, den man da verwendet oder erstellt. Programme und Plugins hingegen, die nur mit dem ERP-System arbeiten und keine Schnittstelle nach anderswo bedienen müssen, brauchen keine Übersetzung. Da hat es mehr Nachteile als Nutzen. Jeder Code kann potentiell Fehler enthalten. Code, den man nicht schreiben muss, hat dieses Potential nicht. Warum sollte ich mir Fehlerpotential ins Programm einbauen, für einen nicht vorhandenen Nutzen?
dedlfix.