Re: [shell32] Improve the Dutch 'about' message box
2009/5/12 Paul Vriens <paul.vriens.wine(a)gmail.com>:
Hi,
Changed the sizes of the buttons and window to be the same as in English. This make sure the 'Wine license' button can be fully read in Dutch.
- DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP + DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP
According to Windows guidelines, command buttons (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x 14 DLUs (they can be wider than 50 DLUs, but only if the text is bigger than that, which it shouldn't for OK buttons) and have a 4 DLU spacing between other controls. This is so they look good in the presence of themes. - Reece
Reece Dunn wrote:
2009/5/12 Paul Vriens <paul.vriens.wine(a)gmail.com>:
Hi,
Changed the sizes of the buttons and window to be the same as in English. This make sure the 'Wine license' button can be fully read in Dutch.
- DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP + DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP
According to Windows guidelines, command buttons (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x 14 DLUs (they can be wider than 50 DLUs, but only if the text is bigger than that, which it shouldn't for OK buttons) and have a 4 DLU spacing between other controls. This is so they look good in the presence of themes.
- Reece Maybe, but doing a simple grep shows:
shell32_Bg.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Cs.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Da.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_De.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP shell32_En.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fi.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fr.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 70, 12, WS_TABSTOP shell32_Hu.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_It.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ja.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Nl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_No.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ro.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ru.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sv.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Uk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP The size of these OK buttons is probably aligned with the other button in that window. -- Cheers, Paul.
Paul Vriens wrote:
Reece Dunn wrote:
2009/5/12 Paul Vriens <paul.vriens.wine(a)gmail.com>:
Hi,
Changed the sizes of the buttons and window to be the same as in English. This make sure the 'Wine license' button can be fully read in Dutch.
- DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP + DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP
According to Windows guidelines, command buttons (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x 14 DLUs (they can be wider than 50 DLUs, but only if the text is bigger than that, which it shouldn't for OK buttons) and have a 4 DLU spacing between other controls. This is so they look good in the presence of themes.
- Reece Maybe, but doing a simple grep shows:
shell32_Bg.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Cs.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Da.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_De.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP shell32_En.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fi.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fr.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 70, 12, WS_TABSTOP shell32_Hu.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_It.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ja.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Nl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_No.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ro.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ru.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sv.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Uk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP
The size of these OK buttons is probably aligned with the other button in that window.
I'm not against changing the size of that OK button to 50x14 but was merely pointing out that this means most of this stuff is not correct. FWIW I was just looking at Outlook 2003 and the OK button on the about window is the same wide as the other buttons (not 50). The page you reference doesn't say anything about adjusting sizes of buttons when multiple (horizontally or vertically) can be found on one page (or at least I didn't see it). -- Cheers, Paul.
Paul Vriens wrote:
Paul Vriens wrote:
Reece Dunn wrote:
According to Windows guidelines, command buttons (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x 14 DLUs (they can be wider than 50 DLUs, but only if the text is bigger than that, which it shouldn't for OK buttons) and have a 4 DLU spacing between other controls. This is so they look good in the presence of themes.
- Reece
Maybe, but doing a simple grep shows:
shell32_Bg.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Cs.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Da.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_De.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP shell32_En.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fi.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fr.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 70, 12, WS_TABSTOP shell32_Hu.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_It.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ja.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Nl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_No.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ro.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ru.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sv.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Uk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP
The size of these OK buttons is probably aligned with the other button in that window.
Sure. There are a lot of places (not just in what you are fixing) that are incorrect. I would like to go through and fix all the layout issues so that the dialogs look nice and are consistent across all the different languages. However, this is a *huge* job. What I would like to do is get an automated (or semi-automated) tool, ideally with a GUI interface to it. That would ultimately put the designer in charge. Hopefully, this would also mean that you have a base resource file that produces the English resources and generate the others using the standard po files - thus making it easier to translate. I'm not sure how far the project should go. And, realistically, at least the core - a command line source+po <==> resource file mapping - should be in Wine as it will need to generate the resource files at runtime (unless a dependency is created on that project)..
I'm not against changing the size of that OK button to 50x14 but was merely pointing out that this means most of this stuff is not correct.
Sure -- see my comments above.
FWIW I was just looking at Outlook 2003 and the OK button on the about window is the same wide as the other buttons (not 50). The page you reference doesn't say anything about adjusting sizes of buttons when multiple (horizontally or vertically) can be found on one page (or at least I didn't see it).
I'm not sure, either. However, I think that consistency is important. - Reece
On Tue, 12 May 2009, Reece Dunn wrote: [...]
What I would like to do is get an automated (or semi-automated) tool, ideally with a GUI interface to it. That would ultimately put the designer in charge. Hopefully, this would also mean that you have a base resource file that produces the English resources and generate the others using the standard po files - thus making it easier to translate.
Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though. But I have just stumbled on this pair of tools from the translate-toolkit packag (on Debian) that seem to be made just for this purpose: * po2rc convert Gettext PO localization files to Windows Resource (.rc) files http://translate.sourceforge.net/wiki/toolkit/rc2po * rc2po convert .rc files to Gettext PO localization files http://translate.sourceforge.net/wiki/toolkit/rc2po I don't have time to play with them but with luck someone else does. Getting it going with Wine would be really great. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.
Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though.
I also think I would be better to use po files (without them, our translations get out-of-sync - e.g. in start a new /Unix switch was intruduced, but only 7 out of 16 languages has it in the help message. For the users of the other 9 languages, we are providing an incorrect help message. This is adding a new line to an existing message, so wrc --verify-translation won't notice it). I was thinking about the widget layout that may need to be different in a translation and I think this can be solved by adding a possibility to add some transformations of controls relative to the English ones. Something like: msgid "transform.dialog.133" msgstr "" "control 12 resize by (10, 10)" "control 13 move by (10, 10)" Making the transformations relative should make updating such resources not very common (and in most cases there will be even no need for this). There may still be cases when it looks ugly if e.g. one adds a new button to the English dialog while the localized ones are enlarged and takes a place where the new button is added, but we could be solved by adding to msgid e.g. a hash of the English resource with localizable stirngs removed, so that the translation will be fuzzy after a merge. I could try to look into po2rc and rc2po if they work and can be augmented with such a functionality, but I'm not sure if I will have time soon. Mikołaj
Mikołaj Zalewski wrote:
Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though.
I also think I would be better to use po files (without them, our translations get out-of-sync - e.g. in start a new /Unix switch was intruduced, but only 7 out of 16 languages has it in the help message. For the users of the other 9 languages, we are providing an incorrect help message. This is adding a new line to an existing message, so wrc --verify-translation won't notice it). I was thinking about the widget layout that may need to be different in a translation and I think this can be solved by adding a possibility to add some transformations of controls relative to the English ones. Something like:
msgid "transform.dialog.133" msgstr "" "control 12 resize by (10, 10)" "control 13 move by (10, 10)"
Making the transformations relative should make updating such resources not very common (and in most cases there will be even no need for this). There may still be cases when it looks ugly if e.g. one adds a new button to the English dialog while the localized ones are enlarged and takes a place where the new button is added, but we could be solved by adding to msgid e.g. a hash of the English resource with localizable stirngs removed, so that the translation will be fuzzy after a merge. I could try to look into po2rc and rc2po if they work and can be
They work, sort of. I tried them out (though not the latest version) and run into a problem where the MENUs where ignored. That is a known problem with complex MENUs according to the description of the tools on their web page.
augmented with such a functionality, but I'm not sure if I will have time soon.
bye michael
2009/5/16 Francois Gouget <fgouget(a)free.fr>:
On Tue, 12 May 2009, Reece Dunn wrote: [...]
What I would like to do is get an automated (or semi-automated) tool, ideally with a GUI interface to it. That would ultimately put the designer in charge. Hopefully, this would also mean that you have a base resource file that produces the English resources and generate the others using the standard po files - thus making it easier to translate.
Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though.
I was thinking of some sort of auto-layout logic, using bounding box calculations and metric information fed from Windows guidelines. The idea here is to give a consistent layout and make it easier to add new controls. I am aware that this is very complex, and I don't yet know how to transform the flat layout to a hierarchical layout that contains the box information necessary to do the reflow calculations.
But I have just stumbled on this pair of tools from the translate-toolkit packag (on Debian) that seem to be made just for this purpose:
* po2rc convert Gettext PO localization files to Windows Resource (.rc) files http://translate.sourceforge.net/wiki/toolkit/rc2po
* rc2po convert .rc files to Gettext PO localization files http://translate.sourceforge.net/wiki/toolkit/rc2po
I don't have time to play with them but with luck someone else does. Getting it going with Wine would be really great.
Nor do I, and others are probably better qualified than me to answer. - Reece
On Mon, 18 May 2009, Reece Dunn wrote: [...]
I was thinking of some sort of auto-layout logic, using bounding box calculations and metric information fed from Windows guidelines. The idea here is to give a consistent layout and make it easier to add new controls.
I am aware that this is very complex, and I don't yet know how to transform the flat layout to a hierarchical layout that contains the box information necessary to do the reflow calculations.
If we go that route, we should probably start from a bounding box-based description of the dialogs, and then generate both the English and the localized dialogs. For instance the glade format seems to be bounding-box based. It also probably already has tools to handle localization. So we could probably start from a English glade file describing a dialog, generate localized versions of that file, and then, for each language, pass the dialog through our bounding-box calculator to convert that to coordinates and generate the corresponding rc files. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
2009/5/18 Francois Gouget <fgouget(a)free.fr>:
On Mon, 18 May 2009, Reece Dunn wrote: [...]
I was thinking of some sort of auto-layout logic, using bounding box calculations and metric information fed from Windows guidelines. The idea here is to give a consistent layout and make it easier to add new controls.
I am aware that this is very complex, and I don't yet know how to transform the flat layout to a hierarchical layout that contains the box information necessary to do the reflow calculations.
If we go that route, we should probably start from a bounding box-based description of the dialogs, and then generate both the English and the localized dialogs.
For instance the glade format seems to be bounding-box based. It also probably already has tools to handle localization. So we could probably start from a English glade file describing a dialog, generate localized versions of that file, and then, for each language, pass the dialog through our bounding-box calculator to convert that to coordinates and generate the corresponding rc files.
Yes. That would be a better way for storing the information. The advantage of choosing something like the Glade format is that we could then take advantage of the editors for the format, so the Wine developers can edit the dialogs visually. A similar thing for the menus. The question here (which applies to any direction that is taken) is whether the format that is chosen can represent all the information in the RC file. The first step would be getting the RC <==> Box format conversion working reliably. Then adding the translation on top of that using the PO/gettext framework. - Reece
participants (5)
-
Francois Gouget -
Michael Stefaniuc -
Mikołaj Zalewski -
Paul Vriens -
Reece Dunn