Übersetzen von Reportvariablen

Hallo combit-Team,

ich versuche mich gerade in der Umsetzung von Mehrsprachigen Reports mit der akt. LL-Version 24.
In der Designervorschau funktioniert die Übersetzung mit Hilfe des ‘Translate$()’-Befehls auch einwandfrei.
Sobald ich aber den Report in der Druckvorschau anzeigen lasse, werden die Werte nicht mehr übersetzt.
Woran kann das liegen?
Soweit ich das feststellen kann sind alle Variablen identisch gesetzt, sowohl im Designmodus als auch im Printmodus.

Vielen Dank für Eure Hilfe
Carsten Ilwig

Was hast Du denn als Sprache für den Druck gewählt? Und was passiert genau? Vielleicht kannst Du mal den mehrsprachigen Bericht in der Demo ausprobieren? Geht es da wie erwartet?

Im Project fülle ich das StatiscTexts-Dictionary wie im Beispiel angegeben:
ll.Dictionary.StaticTexts.Add(“Sprache”, “Language”, _designerLanguageLCIDen); (_designerLanguageLCIDen == 9)
Um es zu testen habe ich der Projektvariablen ‘Sprache für den Druck’ im Designer fest den Wert ‘EN’ zugewiesen. Die Originalsprache ist ‘Deutsch’.
In meinem Report habe ich dann einen Textblock mit diesem Text: Translate$(“Sprache”).
In der Designervorschau wird dann auch korrekt als Text ‘Language’ ausgegeben:
Wenn ich dann den Report als externe Druckvorschau aufrufe steht da aber ‘Sprache’,
also der Originaltext und nicht die Übersetzung.

In der Demo kann ich den Report nicht so einfach verwenden, da er einen recht komplexen Berichtscontainer enthält. Ich hoffe noch, dass ich die Ursache für das Fehlverhalten finden kann ohne aufwendigen Umstellung des Reports , um ihn in der Demo verwenden zu können.

Ich meinte nur, mal den (schon fertigen) Bericht in der Demo auszuprobieren um zu sehen, ob der die gleichen Probleme macht. Bin computerlos im Urlaub, sonst würde ich das selbst ausprobieren.
PS: doofe Frage, nur zur Sicherheit: Du übergibst die Übersetzung sicher auch vor dem Druck?

Meinen Report kann ich ja in der Demo gar nicht laden, da die DataSource dort nicht vorhanden ist.
Doofe Fragen gibst es nicht und ja, soweit ich das feststellen kann übergeb ich die Übersetzungen auch beim Druck und nicht nur beim Designeraufruf.

Also, so wie es aussieht, liegt das Problem an einem Bug in LL24.
Ich habe jetzt den Report in meinem aktuelle Projekt mit LL22 getestet und da funktioniert die Übersetzung in der Druckvorschau einwandfrei.
Genau das Problem mit LL24, dass in der Druckvorschau etwas nicht funktioniert, was aber im Designer einwandfrei funktioniert, habe ich auch schon bei einem anderen Report festgestellt.
Der Fehler dort trat eindeutig erst nach der Umstellung von LL22 auf LL24 auf und betrifft einen Report den ich bereits mit der 11er Version erstellt habe und der bis zum Update einwandfrei funktioniert hat.
.

Dann würde ich mal

a) den Databinding-Modus von Delayload auf Preload umschalten (dann läuft intern einiges anders) und
b) bei combit ein Ticket aufmachen

Jetzt habe ich auch wieder einen Rechner :smile:- bei mir klappt das, in allen Databinding-Modi und auch mit allen Beispielen, insofern wird es vermutlich was spezielleres sein.

PS: LL.DataBindingMode = ... meine ich

Mich würde das auch interessieren - ich kann aktuell kein Problem feststellen. Wann/wo übergeben Sie denn die Übersetzungen? Können Sie einmal Ihren Code (also das Timing und den Ort der Übergabe) mit dem unseres C# Localization-Beispiels vergleichen? Da funktioniert es bei mir.

Guten Morgen,
vielen Dank für die hilfreichen Hinweise.
Ich konnte jetzt die Fehlerstelle ausmachen und beheben.
Sie lag in meiner eigenen LL-Bibliothek.
Da habe ich das LL-Dictionary, welches die Übersetzungen enthält, vor dem Drucken geleert.
Ich habe den Code jetzt korrigiert und sieh da, es funktioniert wie gewünscht. :grinning:
Sorry für den falschen Bugalarm. Der Bug saß vor dem Bildschirm und nicht im LL-Code. :wink:

1 Like

Das Löschen an sich ist eine gute Idee, da die Übersetzung der Identifier zur Druckzeit unnötig ist, damit lässt sich nochmal ein bisschen Performance rauskitzeln :wink: . Das statische Dictionary wird aber in der Tat gebraucht. Schön, dass sich das gelöst hat, Danke für die Info.