Is there a way to reverse the function "mc" in msgcat?
So to get the original string based on the already translated string.
The translated string was created applying the "mc" function on the original string.
Having the result of "mc" can I found out what was the original string?

Many thanks
Alexandru

Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
> Is there a way to reverse the function "mc" in msgcat?
> So to get the original string based on the already translated string.
> The translated string was created applying the "mc" function on the original string.
> Having the result of "mc" can I found out what was the original string?
>
> Many thanks
> Alexandru
AFAIK not directly.But you could intercept the msgcat::mc call like:

rename ::msgcat::mc ::msgcat::mc1
proc ::msgcat::mc args {
set result [::msgcat::mc1 {*}$args]
# here you have the original $args and the translated string in $result
return $result
}

rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
> > Is there a way to reverse the function "mc" in msgcat?
> > So to get the original string based on the already translated string.
> > The translated string was created applying the "mc" function on the original string.
> > Having the result of "mc" can I found out what was the original string?
> >
> > Many thanks
> > Alexandru
> AFAIK not directly.But you could intercept the msgcat::mc call like:
>
> rename ::msgcat::mc ::msgcat::mc1
> proc ::msgcat::mc args {
> set result [::msgcat::mc1 {*}$args]
> # here you have the original $args and the translated string in $result
> return $result
> }
I get it: I would have to save the results of mc to an array or dict.
But this is not going to work for me.
I'm supprised, that this revesed translation is not aready standard.
I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
The next user might switch to English so the the saved german words are meaningless.

Am 22.09.2023 um 08:08 schrieb Alexandru:
> rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
>> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
>>> Is there a way to reverse the function "mc" in msgcat?
>>> So to get the original string based on the already translated string.
>>> The translated string was created applying the "mc" function on the original string.
>>> Having the result of "mc" can I found out what was the original string?
>>>
>>> Many thanks
>>> Alexandru
>> AFAIK not directly.But you could intercept the msgcat::mc call like:
>>
>> rename ::msgcat::mc ::msgcat::mc1
>> proc ::msgcat::mc args {
>> set result [::msgcat::mc1 {*}$args]
>> # here you have the original $args and the translated string in $result
>> return $result
>> }
> I get it: I would have to save the results of mc to an array or dict.
> But this is not going to work for me.
> I'm supprised, that this revesed translation is not aready standard.
> I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
> Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
> The next user might switch to English so the the saved german words are meaningless.

Hi Alexandru,
thank you for the question.
On the practical side, msgcat maintains a dict.
You want an access function to the values and get the keys.
This is doable.

I personally only use Language Tags, e.g.
mc errFile $err

and

mcflset errFile "File error: %s"

So, this would not help you.

Take care,
Harald

Harald Oehlmann schrieb am Freitag, 22. September 2023 um 08:43:01 UTC+2:
> Am 22.09.2023 um 08:08 schrieb Alexandru:
> > rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
> >> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
> >>> Is there a way to reverse the function "mc" in msgcat?
> >>> So to get the original string based on the already translated string.
> >>> The translated string was created applying the "mc" function on the original string.
> >>> Having the result of "mc" can I found out what was the original string?
> >>>
> >>> Many thanks
> >>> Alexandru
> >> AFAIK not directly.But you could intercept the msgcat::mc call like:
> >>
> >> rename ::msgcat::mc ::msgcat::mc1
> >> proc ::msgcat::mc args {
> >> set result [::msgcat::mc1 {*}$args]
> >> # here you have the original $args and the translated string in $result
> >> return $result
> >> }
> > I get it: I would have to save the results of mc to an array or dict.
> > But this is not going to work for me.
> > I'm supprised, that this revesed translation is not aready standard.
> > I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
> > Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
> > The next user might switch to English so the the saved german words are meaningless.
> Hi Alexandru,
> thank you for the question.
> On the practical side, msgcat maintains a dict.
> You want an access function to the values and get the keys.
> This is doable.
>
> I personally only use Language Tags, e.g.
> mc errFile $err
>
> and
>
> mcflset errFile "File error: %s"
>
> So, this would not help you.
>
> Take care,
> Harald
Thanks Harald.
Would id be a good idea to add a new function to msgcat that does the above?

Am 22.09.23 um 14:55 schrieb Alexandru:
> Harald Oehlmann schrieb am Freitag, 22. September 2023 um 08:43:01 UTC+2:
>> Am 22.09.2023 um 08:08 schrieb Alexandru:
>>> rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
>>>> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
>>>>> Is there a way to reverse the function "mc" in msgcat?
>>>>> So to get the original string based on the already translated string.
>>>>> The translated string was created applying the "mc" function on the original string.
>>>>> Having the result of "mc" can I found out what was the original string?
>>>>>
>>>>> Many thanks
>>>>> Alexandru
>>>> AFAIK not directly.But you could intercept the msgcat::mc call like:
>>>>
>>>> rename ::msgcat::mc ::msgcat::mc1
>>>> proc ::msgcat::mc args {
>>>> set result [::msgcat::mc1 {*}$args]
>>>> # here you have the original $args and the translated string in $result
>>>> return $result
>>>> }
>>> I get it: I would have to save the results of mc to an array or dict.
>>> But this is not going to work for me.
>>> I'm supprised, that this revesed translation is not aready standard.
>>> I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
>>> Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
>>> The next user might switch to English so the the saved german words are meaningless.
>> Hi Alexandru,
>> thank you for the question.
>> On the practical side, msgcat maintains a dict.
>> You want an access function to the values and get the keys.
>> This is doable.
>>
>> I personally only use Language Tags, e.g.
>> mc errFile $err
>>
>> and
>>
>> mcflset errFile "File error: %s"
>>
>> So, this would not help you.
>>
>> Take care,
>> Harald
> Thanks Harald.
> Would id be a good idea to add a new function to msgcat that does the above?

No.

It is correct that the settings should be kept in English only. OTOH, I
don't see the need for reverse translation, for at least two reasons:

1. If a settings value was selected, e.g., from a combobox, then you
should save the combobox index or some other unique identifier rather
than the corresponding English text in the settings file. Populating
the combobox with language-specific strings should be part of your
locale-switching implementation.

2. It is a common case that a translated text corresponds to more than
one original (English) text. Which one should then be returned by the
reverse translation? Or can you always guarantee that the message
catalogue is a one-to-one mapping?

GUI toolkits like Gtk or Qt make extensive use of message catalogues.
AFAIK, they have no reverse translation functionality either.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba.nemethi@t-online.de

nemethi schrieb am Freitag, 22. September 2023 um 16:18:06 UTC+2:
> Am 22.09.23 um 14:55 schrieb Alexandru:
> > Harald Oehlmann schrieb am Freitag, 22. September 2023 um 08:43:01 UTC+2:
> >> Am 22.09.2023 um 08:08 schrieb Alexandru:
> >>> rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
> >>>> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
> >>>>> Is there a way to reverse the function "mc" in msgcat?
> >>>>> So to get the original string based on the already translated string.
> >>>>> The translated string was created applying the "mc" function on the original string.
> >>>>> Having the result of "mc" can I found out what was the original string?
> >>>>>
> >>>>> Many thanks
> >>>>> Alexandru
> >>>> AFAIK not directly.But you could intercept the msgcat::mc call like:
> >>>>
> >>>> rename ::msgcat::mc ::msgcat::mc1
> >>>> proc ::msgcat::mc args {
> >>>> set result [::msgcat::mc1 {*}$args]
> >>>> # here you have the original $args and the translated string in $result
> >>>> return $result
> >>>> }
> >>> I get it: I would have to save the results of mc to an array or dict.
> >>> But this is not going to work for me.
> >>> I'm supprised, that this revesed translation is not aready standard.
> >>> I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
> >>> Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
> >>> The next user might switch to English so the the saved german words are meaningless.
> >> Hi Alexandru,
> >> thank you for the question.
> >> On the practical side, msgcat maintains a dict.
> >> You want an access function to the values and get the keys.
> >> This is doable.
> >>
> >> I personally only use Language Tags, e.g.
> >> mc errFile $err
> >>
> >> and
> >>
> >> mcflset errFile "File error: %s"
> >>
> >> So, this would not help you.
> >>
> >> Take care,
> >> Harald
> > Thanks Harald.
> > Would id be a good idea to add a new function to msgcat that does the above?
> No.
>
> It is correct that the settings should be kept in English only. OTOH, I
> don't see the need for reverse translation, for at least two reasons:
>
> 1. If a settings value was selected, e.g., from a combobox, then you
> should save the combobox index or some other unique identifier rather
> than the corresponding English text in the settings file. Populating
> the combobox with language-specific strings should be part of your
> locale-switching implementation.
>
> 2. It is a common case that a translated text corresponds to more than
> one original (English) text. Which one should then be returned by the
> reverse translation? Or can you always guarantee that the message
> catalogue is a one-to-one mapping?
>
> GUI toolkits like Gtk or Qt make extensive use of message catalogues.
> AFAIK, they have no reverse translation functionality either.
>
> --
> Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de
I disagree.
First of all: The original strings are either english nor german. They more like "meanigfull keys".
Those keys are translated into English, German and so on.
Secondly: Saving indexes of comboboxes is a bad idea, since the number or order of options can change in time.
Thirdly: Making the function available as a standard in the package does not mean that everybody should use it.
If I make an effort programming this funtion, then it might as well be available for the rest of the world. I don't see what harm can it do.

* nemethi <csaba.nemethi@t-online.de>
| Am 22.09.23 um 14:55 schrieb Alexandru:
| > Would id be a good idea to add a new function to msgcat that does the above?
>
| No.
>
| It is correct that the settings should be kept in English only. OTOH,
| I don't see the need for reverse translation, for at least two
| reasons:
--<snip-snip>--
| 2. It is a common case that a translated text corresponds to more than
| one original (English) text. Which one should then be returned by
| the reverse translation? Or can you always guarantee that the
| message catalogue is a one-to-one mapping?

In addition, message catalogue keys can contain %-substitutions, which
make a reverse lookup for those very difficult. A generic reverse
lookup would need to handle these somehow.

R'

Ralf Fassel schrieb am Freitag, 22. September 2023 um 16:56:04 UTC+2:
> * nemethi <csaba....@t-online.de>
> | Am 22.09.23 um 14:55 schrieb Alexandru:
> | > Would id be a good idea to add a new function to msgcat that does the above?
> >
> | No.
> >
> | It is correct that the settings should be kept in English only. OTOH,
> | I don't see the need for reverse translation, for at least two
> | reasons:
> --<snip-snip>--
> | 2. It is a common case that a translated text corresponds to more than
> | one original (English) text. Which one should then be returned by
> | the reverse translation? Or can you always guarantee that the
> | message catalogue is a one-to-one mapping?
> In addition, message catalogue keys can contain %-substitutions, which
> make a reverse lookup for those very difficult. A generic reverse
> lookup would need to handle these somehow.
>
> R'
Agree, only that the programmer can decide to use that function or not.
For example, in my case I know that the keys are unique and there are no %-substititions.

Am 22.09.23 um 16:33 schrieb Alexandru:
> nemethi schrieb am Freitag, 22. September 2023 um 16:18:06 UTC+2:
>> Am 22.09.23 um 14:55 schrieb Alexandru:
>>> Harald Oehlmann schrieb am Freitag, 22. September 2023 um 08:43:01 UTC+2:
>>>> Am 22.09.2023 um 08:08 schrieb Alexandru:
>>>>> rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
>>>>>> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
>>>>>>> Is there a way to reverse the function "mc" in msgcat?
>>>>>>> So to get the original string based on the already translated string.
>>>>>>> The translated string was created applying the "mc" function on the original string.
>>>>>>> Having the result of "mc" can I found out what was the original string?
>>>>>>>
>>>>>>> Many thanks
>>>>>>> Alexandru
>>>>>> AFAIK not directly.But you could intercept the msgcat::mc call like:
>>>>>>
>>>>>> rename ::msgcat::mc ::msgcat::mc1
>>>>>> proc ::msgcat::mc args {
>>>>>> set result [::msgcat::mc1 {*}$args]
>>>>>> # here you have the original $args and the translated string in $result
>>>>>> return $result
>>>>>> }
>>>>> I get it: I would have to save the results of mc to an array or dict.
>>>>> But this is not going to work for me.
>>>>> I'm supprised, that this revesed translation is not aready standard.
>>>>> I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
>>>>> Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
>>>>> The next user might switch to English so the the saved german words are meaningless.
>>>> Hi Alexandru,
>>>> thank you for the question.
>>>> On the practical side, msgcat maintains a dict.
>>>> You want an access function to the values and get the keys.
>>>> This is doable.
>>>>
>>>> I personally only use Language Tags, e.g.
>>>> mc errFile $err
>>>>
>>>> and
>>>>
>>>> mcflset errFile "File error: %s"
>>>>
>>>> So, this would not help you.
>>>>
>>>> Take care,
>>>> Harald
>>> Thanks Harald.
>>> Would id be a good idea to add a new function to msgcat that does the above?
>> No.
>>
>> It is correct that the settings should be kept in English only. OTOH, I
>> don't see the need for reverse translation, for at least two reasons:
>>
>> 1. If a settings value was selected, e.g., from a combobox, then you
>> should save the combobox index or some other unique identifier rather
>> than the corresponding English text in the settings file. Populating
>> the combobox with language-specific strings should be part of your
>> locale-switching implementation.
>>
>> 2. It is a common case that a translated text corresponds to more than
>> one original (English) text. Which one should then be returned by the
>> reverse translation? Or can you always guarantee that the message
>> catalogue is a one-to-one mapping?
>>
>> GUI toolkits like Gtk or Qt make extensive use of message catalogues.
>> AFAIK, they have no reverse translation functionality either.
>>
>> --
>> Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de
> I disagree.
> First of all: The original strings are either english nor german. They more like "meanigfull keys".
> Those keys are translated into English, German and so on.
> Secondly: Saving indexes of comboboxes is a bad idea, since the number or order of options can change in time.
> Thirdly: Making the function available as a standard in the package does not mean that everybody should use it.
> If I make an effort programming this funtion, then it might as well be available for the rest of the world. I don't see what harm can it do.

I also spoke of "some other unique identifier" as an alternative to
combobox indices. And this seems to be in line with what you call
"meaningful keys".

Implementing a reverse translation functionality would, of course, do no
harm. But this is not what I referred to. Making use of message
catalogues is a wide-spread technique, which works well in practically
all GUI toolkits in spite of the missing reverse translation
functionality. You are free to stick to your idea of using reverse
translation and wait until somebody implements it, or instead to design
your applications in such a way that they don't need any (completely
uncommon) reverse translation. It is your choice.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba.nemethi@t-online.de

nemethi schrieb am Freitag, 22. September 2023 um 18:25:04 UTC+2:
> Am 22.09.23 um 16:33 schrieb Alexandru:
> > nemethi schrieb am Freitag, 22. September 2023 um 16:18:06 UTC+2:
> >> Am 22.09.23 um 14:55 schrieb Alexandru:
> >>> Harald Oehlmann schrieb am Freitag, 22. September 2023 um 08:43:01 UTC+2:
> >>>> Am 22.09.2023 um 08:08 schrieb Alexandru:
> >>>>> rene schrieb am Freitag, 22. September 2023 um 07:52:25 UTC+2:
> >>>>>> Alexandru schrieb am Donnerstag, 21. September 2023 um 19:51:57 UTC+2:
> >>>>>>> Is there a way to reverse the function "mc" in msgcat?
> >>>>>>> So to get the original string based on the already translated string.
> >>>>>>> The translated string was created applying the "mc" function on the original string.
> >>>>>>> Having the result of "mc" can I found out what was the original string?
> >>>>>>>
> >>>>>>> Many thanks
> >>>>>>> Alexandru
> >>>>>> AFAIK not directly.But you could intercept the msgcat::mc call like:
> >>>>>>
> >>>>>> rename ::msgcat::mc ::msgcat::mc1
> >>>>>> proc ::msgcat::mc args {
> >>>>>> set result [::msgcat::mc1 {*}$args]
> >>>>>> # here you have the original $args and the translated string in $result
> >>>>>> return $result
> >>>>>> }
> >>>>> I get it: I would have to save the results of mc to an array or dict.
> >>>>> But this is not going to work for me.
> >>>>> I'm supprised, that this revesed translation is not aready standard.
> >>>>> I need it to save some user settings from the GUI to a file and the restore them from the file to the GUI.
> >>>>> Since the GUI values are translated (let's say to German), I don't want to write gernan names to the file.
> >>>>> The next user might switch to English so the the saved german words are meaningless.
> >>>> Hi Alexandru,
> >>>> thank you for the question.
> >>>> On the practical side, msgcat maintains a dict.
> >>>> You want an access function to the values and get the keys.
> >>>> This is doable.
> >>>>
> >>>> I personally only use Language Tags, e.g.
> >>>> mc errFile $err
> >>>>
> >>>> and
> >>>>
> >>>> mcflset errFile "File error: %s"
> >>>>
> >>>> So, this would not help you.
> >>>>
> >>>> Take care,
> >>>> Harald
> >>> Thanks Harald.
> >>> Would id be a good idea to add a new function to msgcat that does the above?
> >> No.
> >>
> >> It is correct that the settings should be kept in English only. OTOH, I
> >> don't see the need for reverse translation, for at least two reasons:
> >>
> >> 1. If a settings value was selected, e.g., from a combobox, then you
> >> should save the combobox index or some other unique identifier rather
> >> than the corresponding English text in the settings file. Populating
> >> the combobox with language-specific strings should be part of your
> >> locale-switching implementation.
> >>
> >> 2. It is a common case that a translated text corresponds to more than
> >> one original (English) text. Which one should then be returned by the
> >> reverse translation? Or can you always guarantee that the message
> >> catalogue is a one-to-one mapping?
> >>
> >> GUI toolkits like Gtk or Qt make extensive use of message catalogues.
> >> AFAIK, they have no reverse translation functionality either.
> >>
> >> --
> >> Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de
> > I disagree.
> > First of all: The original strings are either english nor german. They more like "meanigfull keys".
> > Those keys are translated into English, German and so on.
> > Secondly: Saving indexes of comboboxes is a bad idea, since the number or order of options can change in time.
> > Thirdly: Making the function available as a standard in the package does not mean that everybody should use it.
> > If I make an effort programming this funtion, then it might as well be available for the rest of the world. I don't see what harm can it do.
> I also spoke of "some other unique identifier" as an alternative to
> combobox indices. And this seems to be in line with what you call
> "meaningful keys".
>
> Implementing a reverse translation functionality would, of course, do no
> harm. But this is not what I referred to. Making use of message
> catalogues is a wide-spread technique, which works well in practically
> all GUI toolkits in spite of the missing reverse translation
> functionality. You are free to stick to your idea of using reverse
> translation and wait until somebody implements it, or instead to design
> your applications in such a way that they don't need any (completely
> uncommon) reverse translation. It is your choice.
> --
> Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de

I see a third option besides waiting or not doing it: doing it. I was just asking (with focus on the developers of msgcat) if I could write this function as part of the msgcat package. Then it would be available elegantly though the package itself.

You might put your msgcat stuff in an array, like this

set ar(I) [msgcat::mc {I was chosen}]
set ar(you) [msgcat::mc {you were chosen}]
set ar(we) [msgcat::mc {we were chosen}]
....
and then save not a value, but its "address" (ID, as Csaba said).

I.e. if there was chosen "[msgcat::mc {you were chosen}]", then save "ar(you)" instead it. It's easy to get a value from the array, when the value's address is known. And vice versa.

Make a separate file.tcl for the array of "msgcat::mc"'s, to handle it easier.

Alex P schrieb am Sonntag, 24. September 2023 um 21:07:42 UTC+2:
> You might put your msgcat stuff in an array, like this
>
> set ar(I) [msgcat::mc {I was chosen}]
> set ar(you) [msgcat::mc {you were chosen}]
> set ar(we) [msgcat::mc {we were chosen}]
> ...
> and then save not a value, but its "address" (ID, as Csaba said).
>
> I.e. if there was chosen "[msgcat::mc {you were chosen}]", then save "ar(you)" instead it. It's easy to get a value from the array, when the value's address is known. And vice versa.
>
> Make a separate file.tcl for the array of "msgcat::mc"'s, to handle it easier.
Thanks. In the mean while I implemented a msgcat extension (2 procs only) to implement the reversed translation (reversed lookup). Thanks to Harald Oehlmann it's already up there on the branch: https://core.tcl-lang.org/tcl/timeline?r=msgcat-reverse-lookup&c=2023-09-24+18%3A30%3A48

It's important to count a context of usage, which doesn't imply a one-to-one mapping "original-translation", in general.

For example, English words can be translated as nouns or verbs:
[msgcat::mc Name] => Name, Имя etc.
[msgcat::mc Name] => Nennen, Называть etc.

Another distinction is a mode to be used: imperative verb (in most cases) or something else:
[msgcat::mc Name] => Nenne, Назвать etc.
[msgcat::mc Name] => Nennen, Называть etc.

So, the various contexts imply the various translations with msgcat::mc. As for those old examples, we could have

for English users:
set ar(context1,name) [msgcat::mc Name1] ;# => Name
set ar(context2,name) [msgcat::mc Name2] ;# => Name
set ar(context3,name) [msgcat::mc Name3] ;# => Name

for non-English users (here, German, Russian, Ukranian):
set ar(context1,name) [msgcat::mc Name1] ;# => Name, Имя, Ім'я
set ar(context2,name) [msgcat::mc Name2] ;# => Nenne, Назвать, Назвати
set ar(context3,name) [msgcat::mc Name3] ;# => Nennen, Называть, Називати

Rather strange, yes? However, without contexts, some (esp. automated) translations look ugly.

The contexts of usage might be considered in the reversing msgcat::mc function - as well as a context option in args of ::msgcat::mc src-string ?arg arg ...?, now used only to format src-string.