Menu
▾
▴
fvwm-crystal-users
|
From: Dominique M. <dom...@gm...> - 2019-11-16 19:41:01
|
I found a bug when making the French translation. If your language contain the apostrophe "'", to have it into a menu translated string, will screw up the corresponding menu entry and associated function. That imply not only the displayed string can and will be wrong, but that menu entry will not work at all. To escape the "'" into the translation doesn't help, or help randomly in a few cases. The same string into a FvwmForm will work fine. I reported this to the Fvwm workers list, but get no answer at that time. The only workaround I find is to not use "'" into translated menu strings, and when not possible, to replace "'" by something like "_" or " ". I think it will be the same issue with other characters used by fvwm as quoting characters, and I rally hope they will be the only ones causing that issue. Thanks for your time. Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Alwin <tra...@zi...> - 2019-11-17 11:13:34
|
Hi Dominique, I think you're right, and counting how much escape characters would be needed in every single translation string is too much of a burden. It seems that FVWM does the gettext conversion before execution of the scripting task. Using the Unicode apostrophe U+2019 unbackslashed, works under a UTF-8 locale, and it's looking nice. But under another character set (8859-1 family) it's replaced again by the ASCII apostrophe which is also used by the script, so it ruins the menu. Maybe FVWM-Crystal should declare using translations not using UTF-8 broken for the time being, and use the Unicode apostrophe for now. The real solution would probably be, that FVWM doesn't take the 'gt.' string for gettext into account for the scripting part. Cheers, Dominique Michel schreef: > I found a bug when making the French translation. If your language > contain the apostrophe "'", to have it into a menu translated string, > will screw up the corresponding menu entry and associated function. > That imply not only the displayed string can and will be wrong, but that > menu entry will not work at all. To escape the "'" into the > translation doesn't help, or help randomly in a few cases. > > The same string into a FvwmForm will work fine. I reported this to the > Fvwm workers list, but get no answer at that time. The only workaround > I find is to not use "'" into translated menu strings, and when not > possible, to replace "'" by something like "_" or " ". I think it will > be the same issue with other characters used by fvwm as quoting > characters, and I rally hope they will be the only ones causing > that issue. > > Thanks for your time. > Dominique -- [alwin] |
|
From: Dominique M. <dom...@gm...> - 2019-11-22 17:28:25
|
Le Sun, 17 Nov 2019 12:13:17 +0100, Alwin <tra...@zi...> a écrit : > Hi Dominique, Hi Alwin, > > I think you're right, and counting how much escape characters would > be needed in every single translation string is too much of a burden. > > It seems that FVWM does the gettext conversion before execution of > the scripting task. Using the Unicode apostrophe U+2019 > unbackslashed, works under a UTF-8 locale, and it's looking nice. But > under another character set (8859-1 family) it's replaced again by > the ASCII apostrophe which is also used by the script, so it ruins > the menu. Maybe FVWM-Crystal should declare using translations not > using UTF-8 broken for the time being, and use the Unicode apostrophe > for now. Thanks. I changed them to U+2019 into the French translation. And changed a "don\\'t" into fvwm/scripts/FileEditors/ShowDirectories-Help order to use it too. Hopefully, it was the only needed change into the original English. I added a comment about that into your addons/make.pot script. It will be into the pot files, but not necessarily merged into existing po files. Also, I added a section for 2 strings which are into the XDG application menu generated by fvwm-menu-desktop (Alt+A menu). Will you review these changes? It is also a sed with these strings into fvwm/scripts/XDG-Menu. That is to edit the XDG generated menu in order to adapt it to our need. The 2 strings are just reversed, I think the main issue with these 2 strings is than fvwm doesn't provide a translation for them. Cheers, Dominique > > The real solution would probably be, that FVWM doesn't take the 'gt.' > string for gettext into account for the scripting part. > > > Cheers, > > > Dominique Michel schreef: > > I found a bug when making the French translation. If your language > > contain the apostrophe "'", to have it into a menu translated > > string, will screw up the corresponding menu entry and associated > > function. That imply not only the displayed string can and will be > > wrong, but that menu entry will not work at all. To escape the "'" > > into the translation doesn't help, or help randomly in a few cases. > > > > The same string into a FvwmForm will work fine. I reported this to > > the Fvwm workers list, but get no answer at that time. The only > > workaround I find is to not use "'" into translated menu strings, > > and when not possible, to replace "'" by something like "_" or " ". > > I think it will be the same issue with other characters used by > > fvwm as quoting characters, and I rally hope they will be the only > > ones causing that issue. > > > > Thanks for your time. > > Dominique > > -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Alwin <tra...@zi...> - 2019-11-23 15:21:08
|
Dominique Michel schreef: > Le Sun, 17 Nov 2019 12:13:17 +0100, > Alwin<tra...@zi...> a écrit : > >> Hi Dominique, > Hi Alwin, >> I think you're right, and counting how much escape characters would >> be needed in every single translation string is too much of a burden. >> >> It seems that FVWM does the gettext conversion before execution of >> the scripting task. Using the Unicode apostrophe U+2019 >> unbackslashed, works under a UTF-8 locale, and it's looking nice. But >> under another character set (8859-1 family) it's replaced again by >> the ASCII apostrophe which is also used by the script, so it ruins >> the menu. Maybe FVWM-Crystal should declare using translations not >> using UTF-8 broken for the time being, and use the Unicode apostrophe >> for now. > Thanks. I changed them to U+2019 into the French translation. And > changed a "don\\'t" into fvwm/scripts/FileEditors/ShowDirectories-Help > order to use it too. Hopefully, it was the only needed change into the > original English. Yes, that was the only one. > I added a comment about that into your addons/make.pot script. > It will be into the pot files, but not necessarily merged into > existing po files. > Also, I added a section for 2 strings which are into the XDG > application menu generated by fvwm-menu-desktop (Alt+A menu). > Will you review these changes? The quoting problem should be temporary, if it could be fixed in fvwm as a bug. Small change for the same hints in make.pot 'Help', and a slash in the relative path. There's actually a setting in Poedit to add a prefix, so the files can be viewed directly. --- make.pot.old 2019-11-23 13:12:58.752340653 +0100 +++ make.pot 2019-11-23 15:58:25.936137186 +0100 @@ -40,6 +40,10 @@ # to search for empty msgstr's, check translations marked by the `fuzzy' # flag, remove the lines containing `fuzzy', and (optionally) remove # marked obsolete entries at the end of the PO files. +# +# Using quoting characters into a translation can confuse fvwm. +# To avoid this, you MUST use other UTF-8 characters like , ‘ ’ “ ” « or ». +# The most used one can be the apostrophe: please use ’ instead of '. @@ -222,11 +226,11 @@ # put non conventional strings here: if [ "$i" = "fvwm-crystal" ]; then - echo '#: ..fvwm/scripts/XDG-Menu' >>$i.pot + echo '#: ../fvwm/scripts/XDG-Menu' >>$i.pot echo 'msgid "Configure"' >>$i.pot echo 'msgstr ""' >>$i.pot echo '' >>$i.pot - echo '#: ..fvwm/scripts/XDG-Menu' >>$i.pot + echo '#: ../fvwm/scripts/XDG-Menu' >>$i.pot echo 'msgid "Regenerate"' >>$i.pot echo 'msgstr ""' >>$i.pot fi > > It is also a sed with these strings into fvwm/scripts/XDG-Menu. That is > to edit the XDG generated menu in order to adapt it to our need. The 2 > strings are just reversed, I think the main issue with these 2 strings > is than fvwm doesn't provide a translation for them. Then that's probably temporary too. ;-) > > Cheers, > Dominique >> The real solution would probably be, that FVWM doesn't take the 'gt.' >> string for gettext into account for the scripting part. >> >> >> Cheers, >> >> >> Dominique Michel schreef: >>> I found a bug when making the French translation. If your language >>> contain the apostrophe "'", to have it into a menu translated >>> string, will screw up the corresponding menu entry and associated >>> function. That imply not only the displayed string can and will be >>> wrong, but that menu entry will not work at all. To escape the "'" >>> into the translation doesn't help, or help randomly in a few cases. >>> >>> The same string into a FvwmForm will work fine. I reported this to >>> the Fvwm workers list, but get no answer at that time. The only >>> workaround I find is to not use "'" into translated menu strings, >>> and when not possible, to replace "'" by something like "_" or " ". >>> I think it will be the same issue with other characters used by >>> fvwm as quoting characters, and I rally hope they will be the only >>> ones causing that issue. >>> >>> Thanks for your time. >>> Dominique -- [alwin] |
|
From: Dominique M. <dom...@gm...> - 2019-11-22 18:19:18
|
I replaced the "'" by U+2019 into the existing locales everywhere but not in constructs like "\\'path\\'". For these constructs, I think it could be best to change them to "<path>", and that including into the original English. What do you think? Cheers, Dominique Le Sun, 17 Nov 2019 12:13:17 +0100, Alwin <tra...@zi...> a écrit : > Hi Dominique, > > I think you're right, and counting how much escape characters would > be needed in every single translation string is too much of a burden. > > It seems that FVWM does the gettext conversion before execution of > the scripting task. Using the Unicode apostrophe U+2019 > unbackslashed, works under a UTF-8 locale, and it's looking nice. But > under another character set (8859-1 family) it's replaced again by > the ASCII apostrophe which is also used by the script, so it ruins > the menu. Maybe FVWM-Crystal should declare using translations not > using UTF-8 broken for the time being, and use the Unicode apostrophe > for now. > > The real solution would probably be, that FVWM doesn't take the 'gt.' > string for gettext into account for the scripting part. > > > Cheers, > > > Dominique Michel schreef: > > I found a bug when making the French translation. If your language > > contain the apostrophe "'", to have it into a menu translated > > string, will screw up the corresponding menu entry and associated > > function. That imply not only the displayed string can and will be > > wrong, but that menu entry will not work at all. To escape the "'" > > into the translation doesn't help, or help randomly in a few cases. > > > > The same string into a FvwmForm will work fine. I reported this to > > the Fvwm workers list, but get no answer at that time. The only > > workaround I find is to not use "'" into translated menu strings, > > and when not possible, to replace "'" by something like "_" or " ". > > I think it will be the same issue with other characters used by > > fvwm as quoting characters, and I rally hope they will be the only > > ones causing that issue. > > > > Thanks for your time. > > Dominique > > -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Alwin <tra...@zi...> - 2019-11-23 15:21:14
|
That looks fine to me. Although < and > have a special meaning in shell script, I don't think that's the case within quoted strings like "$[gt. ... ]". Dominique Michel schreef: > I replaced the "'" by U+2019 into the existing locales everywhere but > not in constructs like "\\'path\\'". > > For these constructs, I think it could be best to change them to > "<path>", and that including into the original English. What do you > think? > > Cheers, > Dominique > > Le Sun, 17 Nov 2019 12:13:17 +0100, > Alwin<tra...@zi...> a écrit : > >> Hi Dominique, >> >> I think you're right, and counting how much escape characters would >> be needed in every single translation string is too much of a burden. >> >> It seems that FVWM does the gettext conversion before execution of >> the scripting task. Using the Unicode apostrophe U+2019 >> unbackslashed, works under a UTF-8 locale, and it's looking nice. But >> under another character set (8859-1 family) it's replaced again by >> the ASCII apostrophe which is also used by the script, so it ruins >> the menu. Maybe FVWM-Crystal should declare using translations not >> using UTF-8 broken for the time being, and use the Unicode apostrophe >> for now. >> >> The real solution would probably be, that FVWM doesn't take the 'gt.' >> string for gettext into account for the scripting part. >> >> >> Cheers, >> >> >> Dominique Michel schreef: >>> I found a bug when making the French translation. If your language >>> contain the apostrophe "'", to have it into a menu translated >>> string, will screw up the corresponding menu entry and associated >>> function. That imply not only the displayed string can and will be >>> wrong, but that menu entry will not work at all. To escape the "'" >>> into the translation doesn't help, or help randomly in a few cases. >>> >>> The same string into a FvwmForm will work fine. I reported this to >>> the Fvwm workers list, but get no answer at that time. The only >>> workaround I find is to not use "'" into translated menu strings, >>> and when not possible, to replace "'" by something like "_" or " ". >>> I think it will be the same issue with other characters used by >>> fvwm as quoting characters, and I rally hope they will be the only >>> ones causing that issue. >>> >>> Thanks for your time. >>> Dominique -- [alwin] |
Thanks for helping keep SourceForge clean.
X