Dieselben Formulare wurden auf andern DBs benutzt und dort stimmt alles, also nehme ich an dass es NICHT am Formular liegt
Die Einstellungen, die man machen kann, habe ich alle überprüft…Übersetzungstabelle ist gefüllt für ENGLISCH, es ist auch nicht ENGLISCH UK o.ä. …
Kann man irgendwo sehen, dass etwas mit dem “Sprachpaket” nicht stimmt?
Wenn dieselben List & Label‑Formulare mit Translate$() auf einer anderen Datenbank korrekt übersetzen, ist das Formular selbst sehr wahrscheinlich in Ordnung. Dann liegt das Problem typischerweise in der Laufzeitumgebung: der von der Anwendung bereitgestellten Übersetzungs-Tabelle („Wörterbuch“) oder der gewählten Drucksprache.
Ein paar Punkte, die man anhand der Dokumentation sauber eingrenzen kann:
Wie Translate$() überhaupt arbeitet Translate$() übersetzt nur dann, wenn der übergebene Text als Schlüssel im von der Anwendung bereitgestellten Wörterbuch vorhanden ist – und zwar für genau die zur Laufzeit aktive Sprache Translate-Funktion.
Wenn bei Vorschau oder Druck nichts übersetzt wird, heißt das meist:
Das Wörterbuch ist leer oder wird für diese DB gar nicht übergeben, oder
es wird für eine andere Sprache gefüllt als die, die List & Label beim Druck verwendet (z. B. „Englisch UK“ vs. „Englisch“, oder intern ein anderer Sprachcode).Da es mit einer anderen DB funktioniert, ist sehr naheliegend, dass die Anwendung beim Arbeiten mit dieser „Problem‑DB“ entweder:
ein anderes (evtl. leeres) Übersetzungs-Wörterbuch lädt oder
überhaupt kein Wörterbuch an List & Label übergibt.Das kann z. B. in der Applikationslogik an der Mandanten- oder Verbindungs-Konfiguration hängen.
„Sprache für den Druck“ und warum die Vorschau sich anders verhält
Die Eigenschaft „Sprache für den Druck“ (im Projekt unter Projekt > Einstellungen) steht nur zur Verfügung und wirkt nur dann, wenn im Projekt Translate$() verwendet wird und die aufrufende Anwendung diese Option unterstützt Sprache für den Druck. Wichtige Details:
Ist das Feld leer, wird standardmäßig die System- bzw. Anwendungssprache verwendet.
Die Dokumentation weist explizit darauf hin, dass sich diese Einstellung nicht auf die Designer‑Echtdatenvorschau auswirkt Echtdatenvorschau oder Druck.Das bedeutet:
Wenn Sie mit der Echtdatenvorschau im Designer testen, kann es sein, dass die Übersetzung dort gar nicht sichtbar ist, obwohl ein „normaler“ Druck aus der Anwendung heraus korrekt wäre.
Um sicherzugehen, sollten Sie immer auch einen „echten“ Druck/Export aus der Anwendung testen, nicht nur die Designer-Vorschau.
Warum es auf anderen Datenbanken funktioniert
Da dasselbe Formular auf einer anderen DB funktioniert, aber auf der aktuellen nicht, ist es sehr unwahrscheinlich, dass:
das LL‑Projekt falsch ist oder
ein „Sprachpaket“ von List & Label kaputt ist (LL selbst besitzt nur fest definierte Sprachressourcen für die Oberfläche; die Formularübersetzungen kommen immer aus Ihrer Anwendung).Viel mehr spricht das für:
Unterschiedliche Initialisierung der LL‑Komponente je nach Datenbank/Mandant (andere Sprache oder anderes Übersetzungs-Wörterbuch).
Eventuell unterschiedliche Konfigurationen in Ihrer Anwendung pro Datenbank (z. B. in einer Konfiguration ist Englisch als Sprache aktiviert und das Wörterbuch gepflegt, in der anderen nicht).
Was Sie konkret prüfen/abfragen könnenDa Sie selbst „kein Techniker“ sind, wären das typische Fragen/Checks, die Sie bei Ihrer IT/Softwarebetreuung platzieren können:
1. Wird für diese Datenbank beim Aufruf von List & Label ein Übersetzungs-Wörterbuch übergeben?
Beispiel aus dem .NET-Localization-Sample, wie so etwas prinzipiell aussieht: Localization Sample (C#).
Wichtig ist:
Bei DB A und DB B muss die Anwendung denselben Mechanismus nutzen, um die Übersetzungstabelle an LL zu übergeben.
Prüfen lassen: Wird für die „Problem‑DB“ vielleicht schlicht kein Dictionary übergeben oder ein anderes?
Ist die gewünschte Sprache zur Laufzeit wirklich aktiv?
Welche Sprache meldet die Anwendung an LL, wenn mit der „Problem‑DB“ gedruckt wird?
Ist diese Sprache dieselbe, für die die Übersetzungstabelle gefüllt ist (bei Ihnen „ENGLISCH“ und nicht „ENGLISCH (UK)“ o. Ä.)?
Wird die Vorschau, in der Sie testen, von der Anwendung oder vom Designer erzeugt?
Wenn Sie im Designer auf „Echtdatenvorschau“ klicken, greift die Einstellung „Sprache für den Druck“ laut Doku nicht Echtdatenvorschau oder Druck.
Test: Einen Ausdruck/Export direkt aus der Anwendung starten (nicht aus dem Designer) und prüfen, ob dort übersetzt wird.
Stimmen die Schlüssel in der Übersetzungstabelle exakt mit den Texten im Formular überein?
Translate$("Beispieltext") funktioniert nur, wenn genau der String „Beispieltext“ als Schlüssel im Wörterbuch hinterlegt ist Translate-Funktion.
Auf der funktionierenden DB und der Problem-DB sollten Sie idealerweise denselben Schlüsselbestand haben.
Wenn Ihre Software eine „Übersetzungstabelle pro Mandant/DB“ pflegt, kann es sein, dass diese Tabelle für die Problem‑DB schlicht leer oder unvollständig ist.
Zu Ihrer Frage „Sprachpaket prüfen“
In List & Label gibt es keine separaten „Sprachpakete“ für die Projekttexte; LL übersetzt nur, was Ihre Anwendung via Übersetzungs-Wörterbuch liefert. Deshalb kann man auf LL‑Seite selbst kein „Sprachpaket reparieren“.
Was man prüfen kann, liegt in der Anwendung:
Wird für diese DB dasselbe Übersetzungs-Wörterbuch geladen wie für die DB, in der es funktioniert?
Gibt es in Ihrer Anwendung eine Mandanten‑ oder DB‑abhängige Einstellung für „Sprache“ oder „Übersetzung“, die hier anders gesetzt ist?
Das sind viele Ideen/Fragen, die aber alle an die IT-Abteilung bzw. den Hersteller weitergegeben werden sollten.
Hallo Jochen
vielen Dank, richtig, das sind sehr viele Infos, die ich hoffentlich an den richtigen Stellen platzieren kann um die Kollegen eine Lösung finden zu lassen
Ich gebe das feedback dann noch, wenn wir diese Lösung gefunden haben.
Eine schöne und erfolgreiche Woche wünsche ich.
Liebe Grüsse
Sonja
Die Sprache für das Projekt war “de-CH” und hat aus diesem Grunde nichts übersetzt.
mit “de-DE” hat es dann wieder funktioniert wie es sollte…
Danke nochmal für die Tipps! Ich denke, mit der Liste an Möglichkeiten, die Jochen hier ausführlich beschrieben hat, kann man auch in Zukunft mal auf Fehlersuche gehen
