Unsolved translation problem

wolfganguhr

Hello

In some cases we define a label which shall show a parametrized string only.

One example may be a lable in UC_GLBatches.yaml.

this.lblValidDateRange.Text = Catalog.GetString("Valid Date Range:");

Here the lable name lblValidDateRange generates the catalog string "Valid Date Range:"

But inside the manual code I use the real string

lblValidDateRange.Text = String.Format(Catalog.GetString("Valid between {0} and {1}"),
                StringHelper.DateToLocalizedString(StartDateCurrentPeriod, false, false),
                StringHelper.DateToLocalizedString(EndDateLastForwardingPeriod, false, false));

Problem:

One Label creates two catalog strings and the first one is worthless to be used.

Solution:

The automatic solution is our defaul solution for the future.
The label can get an yaml-option like

lblValidDateRange: {manualCodeLabel="Valid between {0} and {1}"}
or
lblValidDateRange: {autocodeLabel="Something specific"}

But in this case the generated code shall looks like:

this.lblValidDateRange.Text = Catalog.GetCatString("lblValidDateRange");

The Catalog.GetString shall remain unchanged and the new Catalog.GetCatString shall be based on the name of the control.

This means that the catalog can be switched during a runtime session.

Catalog.SetLanguage("en-US");  // US-American string
this.lblValidDateRange.Text = Catalog.GetCatString("lblValidDateRange");
Catalog.SetLanguage("de-CH");  // String in German with a Swiss dialect
this.lblValidDateRange.Text = Catalog.GetCatString("lblValidDateRange");

This organisation also avoids ressource chaos if the developer changes the string to from "Valid between {0} and {1}" to "You must not insert dates below {0} or above {1}".

Best regards Wolfgang

christiankatict

Hi Wolfgang,

I understand the Problem: "One Label creates two catalog strings and the first one is worthless to be used." But your solution has the drawback that no translation will happen, because all the translator will see is a string 'lblValidDateRange' that needs to be translated and the translator would have no clue what to do about it!

My proposed solution is this:
The label can get an yaml-option like

lblValidDateRange: {VariableLabelText=true}

The Generator would then omit the creation of the automatic code

this.lblValidDateRange.Text = Catalog.GetString("Valid Date Range:");

and leave it up to the developer to assign a translatable string in the ManualCode file.

The developer would use regular code like

lblValidDateRange.Text = String.Format(Catalog.GetString("Valid between {0} and {1}"),
                StringHelper.DateToLocalizedString(StartDateCurrentPeriod, false, false),
                StringHelper.DateToLocalizedString(EndDateLastForwardingPeriod, false, false));

in the ManualCode file to assign a custom translatable text to the Label.

wolfganguhr

In Visual Basic I have a tool which provides three colums

a) Name of the control
b) String in the 1st language version
c) Field for the translation

May be that we need something like this?

christiankatict

To help me understand this, can you give an example with strings you use in the VB application?

We need to keep in mind that we are limited to the functionality which the C# implementation of GetText can provide - see http://www.gnu.org/software/hello/manual/gettext/C_0023.html - and the functionality of Launchpad, too!

wolfganguhr

Ok that is relative simple. My program was installed eleswhere and the installation routine creates a sub path

/languages/

/languages/english - the english ressources has been stored and in
/languages/german - there are the german ressources

I've had a form like frmSomeName.frm and for each of those forms has an assoziated file frmSomeName.txt containing a content like the following.

lbl_Titel = "Installation of a macro ... "

btn_Cancel = "Cancel"
btn_run = "Start"

lbl_Name_txt = "Name:"
lbl_Pfad_txt = "Path:"

lbl_message = "Important ...!"

if someone wants to translate the program into spanish, he has to create a file

/languages/german/frmSomeName.txt

which holds the ressource.

Some years later Zoschke has sold a vb-language partner which provides a little bit comfort. I've brougt this tool and tested it but from this time I've had only maintenance tasks of old VB-Programs or i've had to write Geman or English only version. So I've no real project. But the structure is very similar except that this are larger and more complex files. The programm scans the code, creates a string table whre the strings can be accessed by the control or variable names.

In this case the developer can set a checkbox for strings which shall not be translated.

The program has internal ressources in English which are used for the first table. This can be changed independently from the sources so even the english gui can be adjusted by someone else. And furthermore all non translated strings are shown in Developer-Englisch.

pokorra

I understand the problem with generated labels, and I first liked the solution proposed by Christian, regarding "VariableLabelText=true" in yaml.
I just realized, that we need to fix csharp\ICT\PetraTools\GenerateI18N\GenerateCatalogStrings.cs, it should not parse generated designer files, otherwise that would not work.

I have created a bug for this: sourceforge.net/apps/mantisbt/o ... php?id=262
I will solve it myself just now, because I have put thought into this already.

Regarding other translation tools, based on the name of the control: I understand your point, Wolfgang. But the gettext approach is used in many programs, and the chaos that you describe can be managed. Old strings will be dropped from the translation file, and new strings will be picked up by the translators.