Language Pack Polnisch - Nicht verfügbar - Workaround?

Moin zusammen,

wir haben bei unserem NAV-Partner gerade eine Anfrage laufen, bei der es sich um die Implementierung eines polnischen Sprachlayers für NAV 2016 dreht.

Leider gibt es seit NAV 2009 R2 kein polnisches Sprachpaket mehr. Über Foreneinträge hier und im WWW bin ich aber auf die Möglichkeit aufmerksam geworden, dass man ein evtl. lückenhaftes 2009R2-Language Pack für Polen in neuere NAV-Versionen implementieren kann.

Die MSDN-Anleitung hier https://msdn.microsoft.com/en-us/library/ee414196%28v=nav.70%29.aspx funktioniert wohl nur, wenn man ausschließlich den Windows Client nutzt. Wir nutzen aber auch den Webclient. Für 2009R2 gab es keinen Webclient.

Unser Partner hat vorgeschlagen, mal in einer Test-Datenbank zu prüfen, was genau "nicht funktioniert", wenn man versucht, das Language Pack aus der alten Version zu importieren. Ich scheitere momentan leider daran,
a) alle Objekte zu kompilieren - ich denke da benötigt man eine Application Designer Lizenz - kann das jemand bestätigen?
b) nach dem mehr oder weniger erfolgreichen Kompilieren die "Caption ML" zu finden, die auf Polnisch vorhanden sein müsste
und
c) dass die Sprache im Windows Client nicht auswählbar ist

Hat hier jemand evtl. den entscheidenden Tipp für mich?

Vielen Dank und Gruß
Christoph

Im Anhang ist das White Paper "Creating Custom Platform Translations", welches beschreibt was für die Erstellung eines eigenen Sprachpakets für Client und Server alles zu tun ist, was u.a. dann für den Webclient erforderlich wäre.

Die Übersetzungen in den Objekten kommen da natürlich dann noch dazu.

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

Die alte Translations.txt kann man als Grundlage für die Objekte verwenden, aber da werden natürlich viele Lücken sein, wegen neuen Tabellen bzw. Feldern oder geänderten Objekten usw.

Da in Polen für Windows Codepage 1250 statt der Westeuropäischen 1252 verwendet wird (bzw. aus alter DOS-Sicht CP 852 statt CP 850, die in C/AL weiterhin gelten), muss man dieses Verfahren verwenden, wenn das in einer DE-Datenbank zusätzlich benötigt wird:
How to: Add Translated Strings for Conflicting Text Encoding Formats
Vergleichbare Implementation siehe hier.

Nur bei gleicher Codepage lassen sich die Objekte direkt mittels PowerShell versorgen, wie hier beschrieben. Der C/AL- Quellcode ist (im Gegensatz zur Datenbank) nicht unicodefähig, erst das neue Format mittels Visual Studio Code, was demnächst als Preview erscheint, wird es erstmals sein. Das kann aber vorerst nur für Extensions benutzt werden.

Testen, ob alle Objekte komplett versorgt sind, kann man ebenfalls mit PowerShell:
Test-NAVApplicationObjectLanguage
Ansonsten gibt es da auch komfortablere Lösungen (mittels Object Manager, Mergetool usw.), kostenlos sind die aber nicht.

Lizenziert (und als Sprachordner vorhanden) muss die Sprache dann auch sein, damit sie wählbar wird.

Vielen Dank, Kai. Das hat mir mal den Horizont aufgezeigt, der da auf einen zukommt.

Ohne Entwickler-Lizenz geht da ja quasi "nix". Insofern werden mir mal abwarten müssen, was unser Partner so sagt.

IT.Integro hat bereits geantwortet und uns mitgeteilt, dass der polnische Sprachlayer nicht ohne polnische Funktionalität vertrieben wird. Bringt uns leider nicht weiter, da wir die lokale Funktionalität für Deutschland mit einem polnischen Sprachlayer benötigen...

Gruß
Christoph

Ohne Entwickler-Lizenz geht da ja quasi "nix".

Nicht ganz, die maschinellen Übersetzungen für die Objekte schon, das Verfahren habe ich hier beschrieben. Die Codes für Polnisch müssen dazu nur im Skript im Switch-Statement hinzugefügt werden, hier also eine Zeile ergänzen.

Code:

"pl" {$NAVTargetlangCode = '-A1045-'}

Dabei

• Translator Hub bzw. DTS trainieren mittels XLIFF-Datei: Mit der alten NAV 2009-Datei, damit im dortigen eigenen Workspace die NAV-Terminologie gelernt wird
• Übersetzungen abfragen: Mit der aktuellen NAV 2016-Datei

Alleine damit hat man dann noch wochenlang zu tun, um diese zu bereinigen, wobei man das aufteilen kann in den formellen Teil (d.h. die typische NAV-Terminologie für Felder, Menüs usw. überall beibehalten, %-Platzhalter kontrollieren usw., das sollte eine mit NAV vertraute Person tun, damit diese durchweg einheitlich sind) und anschließend den rein sprachlichen Aspekt, in erster Linie für lange Texte, das sollte natürlich ein sprachkundiger (ggf. externer) Übersetzer durchführen. Ideal wäre es, wenn eine Person beide Bereiche abdeckt, dann geht es deutlich schneller .

Im Docker Hub ist neuerdings wieder eine von MS bereitgestellte polnische Version (nun natürlich für 365BC) verfügbar.

Code:

bcinsider.azurecr.io/bcsandbox-master:pl

Moin,

IT.Integro hat bereits geantwortet und uns mitgeteilt, dass der polnische Sprachlayer nicht ohne polnische Funktionalität vertrieben wird. Bringt uns leider nicht weiter, da wir die lokale Funktionalität für Deutschland mit einem polnischen Sprachlayer benötigen...

nunja... kaufts halt und spielt nur die Sprachschicht ein? Im Zweifel über den Umweg einer Standard-DB die die IT.Integro Anpassungen enthält? Ist ja auch interessant was die so angepasst haben... so als Referenz wenn man in dem Land einen Geschäftsvorfall hat.
Klingt wie ein verdächtig einfacher Plan... wenn er funktioniert spart man sich das Translationdings-gefrickel.

LG Jens