----------------------------------------------------------------------------------
@MSGID:
<5cb879b6-c51a-49ff-9148-b04f37d5ddb0n@googlegroups.com> 6e1bac8c
@REPLY: 1@tota-refugium.de> 601ff565
@REPLYADDR Alexandru
<alexandru.dadalau@meshparts.de>
@REPLYTO 2:5075/128 Alexandru
@CHRS: CP866 2
@RFC: 1 0
@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> 1@tota-refugium.de>
@RFC-Message-ID:
<5cb879b6-c51a-49ff-9148-b04f37d5ddb0n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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.
--- G2/1.0
* 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