Nп/п : 88 из 100
 От   : Alexandru                           2:5075/128        22 сен 23 21:06:34
 К    : nemethi                                               22 сен 23 07:09:03
 Тема : Re: Reversed translation in msgcat
----------------------------------------------------------------------------------
                                                                                 
@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



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх