CaptionML per Virtuelle Tabelle bei Objekten änderbar?

Hallo,

ist die CaptionML per Virtuelle Tabelle bei Objekten änderbar? Wir müssten auch DEA in CaptionML zu den existierenden Captioneintrag hinzufügen.

Für welche Tabelle soll das sein bzw. warum ist das denn unbedingt nötig? Da virtuelle Tabellen zur Laufzeit erstellt werden, gibt es keine richtige Definition in der man das ändern könnte.

Dafür gibt es die Translatefunktion.
http://msdn.microsoft.com/en-us/library/dd301161.aspx

Betroffene Objekte markieren, über die obige Funktion DEU exportieren (ohne löschen!), in der Captionsdatei dann -A1031- (=DEU) durch -A3079- (=DEA) ersetzen und wieder importieren. Dann werden die DEA-Captions dazugetragen. Der Zeitstempel am Objekt wird dadurch aber auch verändert, muss also ggf. wieder zurückgestellt werden. Wichtig: Die betroffenen Objekte müssen auch beim Import markiert sein.
Andere Länder:
A2055 DES Schweiz
A4103 DEL Luxemburg
A5127 DEC Liechtenstein
Wichtig: Auf gar keinen Fall zwischen Export und Import Codeänderungen vornehmen, dadurch wird dieser ruiniert, das Thema hatten wir hier gerade.

Das ist schon klar, aber für mich ist das trotzdem eine Frage, ob das wirklich nötig ist. Wenn man auf einer DACH-Version basiert, dann sollte DEA bei nicht Vorhandensein auf DEU zurückfallen und damit wäre das Thema erledigt. Oder?

Wenn man auf einer DACH-Version basiert, dann sollte DEA bei nicht Vorhandensein auf DEU zurückfallen und damit wäre das Thema erledigt. Oder?

Nein, für Forms und Pages muss die richtige Landesversion vorhanden sein, sonst kommt Englisch (ENU). Wenn man dagegen Reports druckt (z.B. Rechnungen mit dem Sprachcode des Geschäftspartners), und DEA ist nicht vorhanden, aber DEU, dann wird DEU für DEA angedruckt (das klappt zumindest für die Classic Reports).

Der Zeitstempel am Objekt wird dadurch aber auch verändert, muss also ggf. wieder zurückgestellt werden.

Eine andere Möglichkeit mit Erhalten des Zeitstempels ist dieses Tool, welches die Objekte direkt modifiziert.
NAV Label Duplicator
Max. Größe der Datei: 15 MB

Hier ein Beispiel aus der umgedrehten Perspektive, wie eine DE-Installation in NAV 2013 R2 einen CH-Client mit DES-Captions anzeigt. Da kommen dann sogar drei Sprachen parallel (Deutsch,Englisch und Französisch).

Trilingual.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hmmm... das ist bei mir nicht so. Wenn ich eine DACH-Installation habe, d.h. auch entsprechende Sprachordner im Installationsverzeichnis und Captions für die Standard-Felder, und nun ein individuelles Feld hinzufüge, bei dem ich aber die DES-Caption nicht hinterlege, dann zeigt er mir bei Auswahl von DES als Sprache immer die DEU-Caption an. Deswegen gibt es ja auch die Primary Language ID in der Windows Language. Nach meinem Verständnis nimmt NAV als erstes diese, wenn die ursprüngliche Caption nicht vorhanden ist, und springt erst in zweiter Instanz auf ENU bzw. leer zurück.

d.h. auch entsprechende Sprachordner im Installationsverzeichnis

Wenn die installiert sind, hat man sicherlich ein anderes Verhalten. Davon darf man aber nicht ausgehen, dass zusätzliche Sprachordner im anderen Land vorhanden sind. Die Objekte müssen auch für eine Standardinstallation sofort funktionieren, und da ist jeweils nur eine deutsche Varietät dabei.

Applang1.png

Mit einem DEA Ordner im Programmverzeichnis hätte man beide Sprachen verfügbar.

Applang2.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Davon darf man aber nicht ausgehen, dass zusätzliche Sprachordner im anderen Land vorhanden sind.

Also ich kenne mittlerweile eine ganze Menge Installationen von internationalen Firmen auf Terminalservern, die unterschiedlichste Sprachpakete installiert haben. Die Auswahl wird dann sicherlich nochmal über die jeweilige Landeslizenz des Users limitiert, aber grundsätzlich sind diese vorhanden. Ansonsten müsste man pro Land mindestens eine eigene Installation vorhalten. Dann kann man auch kein echtes Load Balancing mehr betreiben bzw. muss nach Ländern clustern. Außerdem verkompliziert das die Verteilung von Updates und Hotfixes. Von daher halte ich eine Installation mit unterschiedlichsten Sprachordnern jetzt nicht für so abwegig.

Wenn man Objekte für bekannte Umgebungen liefert, wo die zusätzlichen Pakete vorhanden sind und die Lizenzen entsprechend erweitert wurden und das so vereinbart ist, kann man darauf verzichten. Wenn allerdings Objekte zur allgemeinen Verwendung geliefert werden, muss nicht nur DEA bzw. DES dazu sondern auch DEU entfernt werden. Wir liefern ständig an andere Partner in AT und CH aus, die dann den Endkunden betreuen. Andere Auslieferungsarten werden da nicht akzeptiert.

Versteh ich nicht. Wird unter DACH 2013 nicht mehr DEU mit installiert? Ansonsten betrifft das einen doch nur, wenn man eine W1-Installation nur mit DEA-Sprachpaket installiert hat. Und selbst da kann man sich die Frage stellen, warum es für eine virtuelle Tabelle unbedingt nötig ist, die in Landessprache zu zeigen. Deswegen fragte ich ja, worum es genau geht, denn die meisten virtuellen Tabellen kommen im normalen, täglichen Gebrauch von NAV gar nicht vor bzw. verhindern nicht das flüssige Arbeiten, wenn sie nicht in der Landessprache angezeigt werden.

Ansonsten, wenn ich DACH gekauft habe, würde ich als Kunde auch erwarten, dass mein Partner mir Neuerungen auch als DACH (also mit ENU und DEU) ausliefert, in speziellen Fällen auch mit DEA bzw. DES, FRS und ITS. Wobei CH da sicherlich wesentlich komplizierter ist, da man für die o.g. Fallback-Strategie auch noch FRA- und ITA-Sprachpakete installieren oder eben mit ENU leben müsste.

wenn ich DACH gekauft habe/Wird unter DACH 2013 nicht mehr DEU mit installiert?

Ich weiß nicht, woher du das die ganez Zeit nimmst?
Es gibt keine DACH-Datenbank, nur jeweils eine DE-, AT- und CH-Datenbank (mit je deren spezifischen Sprachlayern).
(Diese unterschiedlichen Datenbanken teilen sich jedoch - zu einem Großteil - eine DACH-Codebasis.)

Ich habe doch gar nicht behauptet, dass es eine DACH-Datenbank automatisch mit allen Sprachpaketen aus dem deutschsprachigen Raum gibt. Schon klar, dass man da immer was tun muss. Wie gesagt, ich weiß nicht genau, was sich mit 2013 diesbezüglich geändert hat. Früher war es jedenfalls so, dass man seine Installation auf einer DACH mit DEU-Sprachpaket aufbauen (war i.d.R. auch die erste, die fertig war) und anschließend die entsprechenden anderen, benötigten Sprachpakete und Landesspezifika nachinstallieren konnte. Was für einen Sinn hätte sonst die gemeinsame Codebasis und insbesondere auch die Primary Language ID?

Das war eine ernst gemeinte Frage, denn ich lerne immer gerne dazu. Ich verstehe das wirklich nicht. Ich meine, wenn ich mich für eine reine Landesdatenbank entschieden habe, wie kann es dann virtuelle Tabellen geben, die meinen (meist sogar einzigen) Sprachlayer nicht bereitstellen? Sollte das dann nicht ein Bug sein?

Luc van Vugt hat hier gegenübergestellt, wie unterschiedlich CC und RTC in NAV 2009 beim Fehlen der passenden Caption reagieren:
http://dynamicsuser.net/blogs/vanvugt/a ... d-rtc.aspx

Das erklärt wie der Anzeigename eines Feldes oder Controls anhand der vorhandenen und nicht vorhandenen Captions gezogen wird. Im Prinzip ist es so wie ich schon sagte. Das erklärt aber nicht, wie man eine virtuelle Tabelle haben kann, in der die einzige Landessprache, die man hat, nicht vorhanden ist. Nach meinem bisherigen Verständnis ist das entweder ein Bug oder man hat keine reine Landesinstallation, sondern irgendetwas gemischtes. Sei es gewollt, dann würde ich aber auf meine Argumente oben verweisen, oder ungewollt, dann hat man nachträglich irgendetwas falsches installiert oder überspielt.