[gelöst] Codepage Problem beim Einspielen einer flm-Datei

Hallo zusammen,
wir brauchen Nav auf französisch (Schweiz). Das Standard-Sprachmodul habe ich runtergeladen und installiert - läuft.
Problematisch sind nun die Module unseres Dienstleisters, der leider keine Übersetzung anbietet. Deshalb haben wir uns über Translate-->Export eine Excel-Datei zur Verfügung stellen lassen, die wir selbst übersetzt haben. Auf dieser Basis hat unser Dienstleister eine .flm-Datei erstellt, die nun eingelesen werden soll. Leider passt die Codepage nicht und ziemlich viele sprachtypische Zeichen sehen unmöglich aus. Die erhaltene .flm-Datei ist in Ansi kodiert und sieht gut aus. Ich habe sie auch in Codepage 850 und 863 (french) gespeichert und versucht einzuspielen, aber leider ohne Erfolg.
Kann mir jemand sagen, was ich noch tun kann damit es funktioniert?

Viele Grüße,
Uta Goldberg

Zuletzt geändert von UGo am 27. Oktober 2023 15:22, insgesamt 1-mal geändert.

Die erhaltene .flm-Datei ist in Ansi kodiert und sieht gut aus.

Das darf sie nicht, wenn man Notepad++ auf Codepage 850 umstellt, dann müssen die Captions richtig aussehen, also alle Sonderzeichen korrekt dargestellt werden.
Mit Konvertierungstools kommt man da nicht weiter, weil dann auch andere Zeichen in der Datei verändert werden, die nichts mit den Captions zu tun haben. Die flm-Datei muss also richtig geliefert werden. Wenn man aus NAV exportiert, ist die auch in Codepage 850, vorausgesetzt, dass die Textdatei bei Translate ->Import auch die richtige Codepage (ebenfalls 850) hatte. Vermutlich ist da bei eurem Dienstleister der Fehler passiert, der ist aber bei einer reinen Textdatei leicht zu beheben, z.B. mit den Skripten hier.

Hallo,

Wenn man aus NAV exportiert, ist die auch in Codepage 850, vorausgesetzt, dass die Textdatei bei Translate ->Import auch die richtige Codepage (ebenfalls 850) hatte

Was zu überprüfen wäre, denn der alte NAV-Client verwendet je nach Länderversion unterschiedliche Code-Pages. D.h. ein Export mit dem französischem Client muss nicht zwangsläufig auch mit dem Deutschen funktionieren, was übrigens auch für die Oberfläche des Clients gilt. Womit das Thema u.U. scheitert, denn was im deutschen Client auf deutsch korrekt aussieht. muss in einem französischen nicht unbedingt korrekt aussehen.
Ich gehe aber mal davon aus, das die Schweiz in allen Sprachen die gleiche Codepage verwendet.

Gruß Fiddi

. Womit das Thema u.U. scheitert, denn was im deutschen Client auf deutsch korrekt aussieht. muss in einem französischen nicht unbedingt korrekt aussehen.

Das ist gleich, DE, CH und FR haben alle Codepage 850 bzw. bei Nicht-Unicode in Windows ANSI 1252 für Westeuropa. Solche Dinge muss man z.B. bei Zentraleuropa (852 in PL,CZ,HU), Baltikum (775) usw. beachten, da weichen die ab (und Codepage 863 ist Französisch in Kanada).

Hallo ihr,

ich kann euch leider nicht folgen. Öffne ich meine flm-Datei im Notepad++ und stelle sie auf OEM850, dann werden alle Sonderzeichen richtig angezeigt.
Ich vermute deshalb das Problem eher beim Einlesen der Datei in Nav. Kann man da noch was einstellen?

Gruß,
Uta

Zuletzt geändert von UGo am 21. August 2023 14:03, insgesamt 1-mal geändert.

Öffne ich meine flm-Datei im Notepad++, dann werden alle Sonderzeichen richtig angezeigt

Genau das ist falsch, erst wenn man den Editor auf Codepage 850 umstellt, dann müssen die stimmen.

NotepadPP850.png

Das ist keine Konvertierung in diese Codepage, nur die Darstellung ist dann so, wie NAV sie nach dem Import auch darstellt. Eine andere Codepage kann man in NAV auch nicht einstellen, diese Einstellung kommt ja jeweils vom Betriebssystem.

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

Ab NAV 2013 R2 geht es auch so: Alternativ kann man auch auf den Dienstleister und die flm verzichten und die Textdatei in Unicode UTF-8 auf dem Server ablegen, siehe Links hier. Also nach Translate -> Export per Skript von Codepage 850 nach UTF-8 konvertieren und dann einfach im Ordner (C:\Program Files\Microsoft Dynamics NAV\71\Service\Translations bzw. C:\Program Files\Microsoft Dynamics NAV\71\Service\Instances\<MyInstance>\Translations) ablegen.

Ab NAV 2013 R2 geht es auch so: Alternativ kann man auch auf den Dienstleister und die flm verzichten und die Textdatei in Unicode UTF-8 auf dem Server ablegen, siehe Links hier. Also nach Translate -> Export per Skript von Codepage 850 nach UTF-8 konvertieren und dann einfach im Ordner (C:\Program Files\Microsoft Dynamics NAV\71\Service\Translations bzw. C:\Program Files\Microsoft Dynamics NAV\71\Service\Instances\<MyInstance>\Translations) ablegen.

Das wäre der einfachste Weg - habe eine UTF8-Datei dort abgelegt und den Serverdienst neu gestartet. Aber weder in der Oberfläche noch in den Nav-Objekten sehe ich eine Änderung.

In den Objekten passiert da auch nichts, die Captions werden zur Laufzeit geholt.
Jede erforderliche Caption benötigt ihren Gegenpart, also wie im Dateivergleich hier ENU A1033 <-> FRA A1036, bei FR in CH (FRS) wäre es dann statt A1036 A4108.
Ist das ein System in DE oder CH? Die zusätzliche Sprache muss auch in der Lizenzdatei freigeschaltet und installiert sein (in CH Standard, in DE eher selten), wenn man auf diese in der GUI umschalten möchte. Lediglich wenn man nur in einem Report diese Sprache verwenden möchte (z.B. DE-System druckt Belege für CH auf Französisch), muss die Lizenz nicht dafür erweitert werden.

Ich habe mir von Microsoft das Sprachpaket Französisch (CH) heruntergeladen und installiert. Im Client kann man jetzt umschalten und erhält für alle Objekte aus dem Nav-Standard die französischen Texte.
Ich gehe also davon aus, dass die Lizenz passt.

Leider ändert sich in der Oberfläche gar nichts.

Ist der flm-Import mit den falschen Sonderzeichen komplett aus NAV gelöscht worden? Dazu müssen alle betroffenen Objekte markiert und die Sprachlayer mit der Option „Sprache löschen“ exportiert werden.

In den Objekten darf danach nichts mehr für Sprache FRS vorhanden sein. Die flm mit den Standardcaptions muss man dann noch mal importieren, um die wiederherzustellen.

Pro Control darf es auch danach jeweils nur eine Übersetzung geben, objektinterne haben Priorität vor denen in den Metadaten, die sich aus der UTF-8-Datei im Serverordner ergeben.

In der Techdays Keynote aus 2013 ab 01:07:00 bis 01:15:20 wurde das damals neue Feature seinerzeit vorgestellt: NAV TechDays 2013 Opening Keynote about NAV 2013 R2