@MSGID: 1@tota-refugium.de> 601ff565
@REPLY:
<aa322a83-d94d-477a-9ef8-50f3514694ben@googlegroups.com> 17c6a53e
@REPLYADDR nemethi <csaba.nemethi@t-online.de>
@REPLYTO 2:5075/128 nemethi
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@tota-refugium.de>
@RFC-References:
<cce3de74-4d91-475a-b45a-4ec3b25567f7n@googlegroups.com> <91c7f56e-29be-4436-9a82-c2ffe7964b36n@googlegroups.com>
<14bd951f-856c-4641-b580-51c4d0f43828n@googlegroups.com> 1@dont-email.me>
<d9b3d63c-9ec4-490a-bfd9-9b0aeebacab6n@googlegroups.com> 1@tota-refugium.de>
<aa322a83-d94d-477a-9ef8-50f3514694ben@googlegroups.com>
@TZUTC: 0200
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:102.0)
Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
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

 --- Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441