Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files.
Isn't that unnecessary?
http://wiki.winehq.org/SublangNeutral says the search order is
1. LANG_NEUTRAL, SUBLANG_NEUTRAL 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN 3. LANG_FRENCH, SUBLANG_NEUTRAL 4. LANG_ENGLISH, SUBLANG_ENGLISH_US
Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats.
Or doesn't a fallback mechanism always apply?
Frédéric
On 06/19/2010 04:09 PM, Frédéric Delanoy wrote:
Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files.
Isn't that unnecessary?
http://wiki.winehq.org/SublangNeutral says the search order is
- LANG_NEUTRAL, SUBLANG_NEUTRAL
- LANG_FRENCH, SUBLANG_FRENCH_BELGIAN
- LANG_FRENCH, SUBLANG_NEUTRAL
- LANG_ENGLISH, SUBLANG_ENGLISH_US
Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats.
Or doesn't a fallback mechanism always apply?
The fallback mechanism works only at resource granularity not a string level. A resource is is a menu, dialog, 16 STRINGTABLE strings, etc. Thus to not break a resource one has to copy the English string over. The move to PO files will fix this.
bye michael
Michael Stefaniuc wrote:
On 06/19/2010 04:09 PM, Frédéric Delanoy wrote:
Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files.
Isn't that unnecessary?
http://wiki.winehq.org/SublangNeutral says the search order is
- LANG_NEUTRAL, SUBLANG_NEUTRAL
- LANG_FRENCH, SUBLANG_FRENCH_BELGIAN
- LANG_FRENCH, SUBLANG_NEUTRAL
- LANG_ENGLISH, SUBLANG_ENGLISH_US
Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats.
Or doesn't a fallback mechanism always apply?
The fallback mechanism works only at resource granularity not a string level. A resource is is a menu, dialog, 16 STRINGTABLE strings, etc. Thus to not break a resource one has to copy the English string over. The move to PO files will fix this.
Another good reason to drop .rc files and go with the po flow...
James McKenzie
James McKenzie jjmckenzie51@earthlink.net wrote:
Another good reason to drop .rc files and go with the po flow...
Not really. If you'd know what stuff the .rc files contain you wouldn't do such claims. The .rc files can't go away in general. James, please learn subject before commenting.
Dmitry Timoshkov wrote:
James McKenzie jjmckenzie51@earthlink.net wrote:
Another good reason to drop .rc files and go with the po flow...
Not really. If you'd know what stuff the .rc files contain you wouldn't do such claims. The .rc files can't go away in general. James, please learn subject before commenting.
Dmitry:
I know what .rc files do. I also know that adding .po functionality will reduce the size of the .rc files. Also, adding a new language will not take as much effort and will allow build-out in stages. That is one of the wonderful features of using these files. Right now, we are missing major language groups. Adding .po functionality might make it easier to add them.
And my comment was that it appears that Wine is making a stride forward to assist those whose native language is NOT English.
James McKenzie
On Sun, 20 Jun 2010, Dmitry Timoshkov wrote:
James McKenzie jjmckenzie51@earthlink.net wrote:
Another good reason to drop .rc files and go with the po flow...
Not really. If you'd know what stuff the .rc files contain you wouldn't do such claims. The .rc files can't go away in general.
James never meant that Wine would not use rc files at all. What he meant is that rc files would lose their status as the autoritative source for the resource strings and would be mostly generated from po files.
James, please learn subject before commenting.
Doubly so before dishing out harsh critisism. James' meaning was obvious for anyone remotely involved in the move to po files.
Francois Gouget fgouget@free.fr wrote:
James never meant that Wine would not use rc files at all. What he meant is that rc files would lose their status as the autoritative source for the resource strings and would be mostly generated from po files.
The .rc files are much more than just strings, in any case the translator need to edit/check the .rc files to get an acceptable result. I was replying to a comment saying basically "me too" which the sender tends to reply to almost every message.
On Wed, 23 Jun 2010, Dmitry Timoshkov wrote:
Francois Gouget fgouget@free.fr wrote:
James never meant that Wine would not use rc files at all. What he meant is that rc files would lose their status as the autoritative source for the resource strings and would be mostly generated from po files.
The .rc files are much more than just strings, in any case the translator need to edit/check the .rc files to get an acceptable result.
Which is something that translators have not all been doing because verifying that the dialog looks ok is such a pain. Currently translators need two have two completely distinct skillsets: * An English to the target language translator skill. * An rc file editing, testing and resizing skill.
Requiring that translators master both skills severly limits the pool of translators we can draw from. Introducing po files lets us treat each task independently and leverage all the online po translation tools.
We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time.
I was replying to a comment saying basically "me too" which the sender tends to reply to almost every message.
The sender is excited by the prospect of rc files being used for translating Wine resources and that's pretty understandable. I am too!
Francois Gouget fgouget@free.fr wrote:
Requiring that translators master both skills severly limits the pool of translators we can draw from.
Doesn't this sound similar to so called limitation that exists for people willing to work on Wine code, but have no appropriate skills? I.e. there is always a choice between quality and quantity.
Introducing po files lets us treat each task independently and leverage all the online po translation tools.
We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time.
Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant.
I was replying to a comment saying basically "me too" which the sender tends to reply to almost every message.
The sender is excited by the prospect of rc files being used for translating Wine resources and that's pretty understandable. I am too!
Good to know.
On 06/25/2010 11:04 AM, Dmitry Timoshkov wrote:
Francois Gougetfgouget@free.fr wrote:
We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time.
Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant.
Once we start using po files we can probably get rid of the 'transl' website as those stats will come from whatever tool we choose to deal with po files.
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
Paul Vriens paul.vriens.wine@gmail.com wrote:
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation?
On 06/25/2010 11:23 AM, Dmitry Timoshkov wrote:
Paul Vrienspaul.vriens.wine@gmail.com wrote:
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation?
Well, nothing is wrong with that I guess. It's however geared to people who are coders, not?
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
On 6/25/2010 13:29, Paul Vriens wrote:
On 06/25/2010 11:23 AM, Dmitry Timoshkov wrote:
Paul Vrienspaul.vriens.wine@gmail.com wrote:
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation?
Well, nothing is wrong with that I guess. It's however geared to people who are coders, not?
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Hi.
Personally I don't see anything complicated or wrong about using .rc files, but yes, it's a bit painful for a contributor that wants to spend some time and discovers that he needs to do some rebuild-n-resize iterations to make it look nice. So correct me if I'm wrong - a po file could be tested without rebuild, right?
For a problem with adjusting sizes we could find some free resource GUI tool I guess that creates a dialog as a IDE form designer, and allows for changes made to go directly to rc (with a way to simply switch languages of course). If there's a such way to do I don't see any problem for a non-coders to make changes.
Paul Vriens paul.vriens.wine@gmail.com wrote:
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation?
Well, nothing is wrong with that I guess. It's however geared to people who are coders, not?
Of course not, that's proven by the amount of new translations we see these days from new people, who apparently are not coders.
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
On 06/25/2010 11:44 AM, Dmitry Timoshkov wrote:
Paul Vrienspaul.vriens.wine@gmail.com wrote:
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation?
Well, nothing is wrong with that I guess. It's however geared to people who are coders, not?
Of course not, that's proven by the amount of new translations we see these days from new people, who apparently are not coders.
Yes, but that also sometimes requires volunteers to do the actual work (editing the resource files and creating patches) for them. I mean, I did a lot of work for Danish and Michael is doing the same for Romanian. It would be much nicer if that can be automated in some way.
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
Fine, let's call it editing an up to date file and creating a patch out of that.
Paul Vriens paul.vriens.wine@gmail.com wrote:
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
Fine, let's call it editing an up to date file and creating a patch out of that.
Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case?
Dmitry Timoshkov wrote:
Paul Vriens paul.vriens.wine@gmail.com wrote:
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
Fine, let's call it editing an up to date file and creating a patch out of that.
Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case?
Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from.
bye michael
Michael Stefaniuc mstefani@redhat.com wrote:
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
Fine, let's call it editing an up to date file and creating a patch out of that.
Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case?
Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from.
How is that different from transalting an .rc file and generating a patch from the resulting translation?
Dmitry Timoshkov wrote:
Michael Stefaniuc mstefani@redhat.com wrote:
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
Fine, let's call it editing an up to date file and creating a patch out of that.
Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case?
Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from.
How is that different from transalting an .rc file and generating a patch from the resulting translation?
For Alexandre there is no difference; he gets a patch on wine-patches and does his emacs magic on it. But we do not care about Alexandre here ;)
For the translator it is a matter of just pressing "Submit" in the web translation tool he used. I hope I don't have to explain the differences to the manual git way... ;)
bye michael
Michael Stefaniuc mstefani@redhat.com wrote:
How is that different from transalting an .rc file and generating a patch from the resulting translation?
For Alexandre there is no difference; he gets a patch on wine-patches and does his emacs magic on it. But we do not care about Alexandre here ;)
For the translator it is a matter of just pressing "Submit" in the web translation tool he used. I hope I don't have to explain the differences to the manual git way... ;)
So, is it Alexandre or somebody else who is responsible for verifying that the translation is acceptable, and doesn't break existing layout of controls, and doesn't break other things because the translator simply didn't see things like a requirement written in capital letters in comdlg32 .rc files that common dialogs should not be resized?
On 06/25/2010 12:08 PM, Dmitry Timoshkov wrote:
Paul Vrienspaul.vriens.wine@gmail.com wrote:
What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages.
Since when the editing of .rc files started to require coding skills?
Fine, let's call it editing an up to date file and creating a patch out of that.
Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case?
I'm actually not sure if somebody already has an idea how to approach this. I guess that we will end up with both resource files and po files in our tree and that we indeed will have patches to po files as well.
The difference however could be that we could have a translation tool in place (for example Pootle if that's viable) that automatically generates the patches and sends them to wine-patches. One can even think of some 'approval layer' in between to verify if the translations actually messes up the layout.
Why don't we add this as a nice topic for the next WineConf?
On Fri, Jun 25, 2010 at 11:14, Paul Vriens paul.vriens.wine@gmail.comwrote:
On 06/25/2010 11:04 AM, Dmitry Timoshkov wrote:
Francois Gougetfgouget@free.fr wrote:
We will still need people to take on the somwhat unsexy control resizing
task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time.
Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant.
Once we start using po files we can probably get rid of the 'transl' website as those stats will come from whatever tool we choose to deal with po files.
For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible?
Why reinventing the wheel? Such a tool already exists (ResHacker or similar). What we should do to attract more people is to provide a more "user-friendly" web page/ translator page explaining in greater detail: - how to find what has to be translated (translation statistics, .rc files, ...) - how to edit a file (#pragma code_page, encoding, menu accelerators, ...) - how to check/adapt actual results with ResHacker, since you have to either adapt the text to fit in, or the dialogs size) - how to create a patch OR send it to e.g. translation@winehq.org for inclusion
I may help in doing this.
Furthermore, on the main web page, "Development - Become a Wine developer" can be intimidating for some potential translators (most non-developers potential translators would not consider themselves... well... developers!). Maybe something like "Contribute - How you can help" (or similar) would be less repulsive.
Frédéric
On Fri, 25 Jun 2010, Dmitry Timoshkov wrote:
Francois Gouget fgouget@free.fr wrote:
Requiring that translators master both skills severly limits the pool of translators we can draw from.
Doesn't this sound similar to so called limitation that exists for people willing to work on Wine code, but have no appropriate skills?
Absolutely not. For the coding part there is no other choice. For translations we can do better by reusing existing tools.
[...]
Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant.
You seem to think that the current situation results in a few translations with perfectly laid out dialogs. I did a few simple tests that make me pretty skeptical of that:
dlls/comdlg32/cdlg_En.rc: LTEXT "List Files of &Type:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Eo.rc: LTEXT "Dosier&speco:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Wa.rc: LTEXT "Djveye des fitchs del sr&te:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Fi.rc: LTEXT "&Luettele tiedostot tyypeittin:", 1089, 6, 104, 90, 9 [27 more]
dlls/msvfw32/msvfw32_En.rc: PUSHBUTTON "&About...",883,129,52,49,14 dlls/msvfw32/msvfw32_Da.rc: PUSHBUTTON "O&m...",883,129,52,49,14 dlls/msvfw32/msvfw32_Ru.rc: PUSHBUTTON "&Информация...",883,129,52,49,14 dlls/msvfw32/msvfw32_Uk.rc: PUSHBUTTON "&Інформація...",883,129,52,49,14 [14 more]
dlls/shell32/shell32_Ja.rc: LTEXT "Wine was brought to you by:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Es.rc: LTEXT "Wine le ha sido proporcionado por:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Si.rc: LTEXT "Wine smo ustvarili:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Sv.rc: LTEXT "Wine hade inte varit mjligt utan dessa personer:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 [18 more]
dlls/winspool.drv/En.rc: LTEXT "&Output File Name:", -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/Pl.rc: LTEXT "&Nazwa pliku do ktrego ma by zapisany wydruk:", -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/No.rc: LTEXT "&Ut-fil:", -1, 7, 13, 194, 13, WS_VISIBLE [19 more]
These were picked at random. Isn't it strange how all these translated controls have the same size as the English version despite widely different text content?
So in fact all you get with the status-quo is few translations *AND* broken dialog layouts.
Francois Gouget fgouget@free.fr wrote:
[skipped]
These were picked at random. Isn't it strange how all these translated controls have the same size as the English version despite widely different text content?
There is nothing strange there, if the text still fits and doesn't get clipped out.
So in fact all you get with the status-quo is few translations *AND* broken dialog layouts.
Same position and size of the controls in different languages doesn't suddenly make the dialog layout broken.
Dmitry wrote:
These were picked at random. Isn't it strange how all these translated controls have the same size as the English version despite widely different text content?
There is nothing strange there, if the text still fits and doesn't get clipped out.
Let's check it out then:
dlls/comdlg32/cdlg_En.rc: LTEXT "List Files of &Type:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Eo.rc: LTEXT "Dosier&speco:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Wa.rc: LTEXT "Djveye des fitchs del sr&te:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Fi.rc: LTEXT "&Luettele tiedostot tyypeittin:", 1089, 6, 104, 90, 9
As expected Wallon and Finnish are truncated: http://fgouget.free.fr/tmp/reshack/comdlg32_Wa.jpg http://fgouget.free.fr/tmp/reshack/comdlg32_Fi.jpg
dlls/msvfw32/msvfw32_En.rc: PUSHBUTTON "&About...",883,129,52,49,14 dlls/msvfw32/msvfw32_Da.rc: PUSHBUTTON "O&m...",883,129,52,49,14 dlls/msvfw32/msvfw32_Ru.rc: PUSHBUTTON "&Информация...",883,129,52,49,14 dlls/msvfw32/msvfw32_Uk.rc: PUSHBUTTON "&Інформація...",883,129,52,49,14
I couldn't check Russian and Ukranian due to font issues, but Italian at least is truncated: http://fgouget.free.fr/tmp/reshack/msvfw32_It.jpg
dlls/shell32/shell32_Ja.rc: LTEXT "Wine was brought to you by:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Es.rc: LTEXT "Wine le ha sido proporcionado por:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Si.rc: LTEXT "Wine smo ustvarili:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Sv.rc: LTEXT "Wine hade inte varit mjligt utan dessa personer:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10
You were right about this string, it's in a field large enough that it does not get trucated. The 'About...' button is not so lucky however: http://fgouget.free.fr/tmp/reshack/shell32_Es.jpg http://fgouget.free.fr/tmp/reshack/shell32_It.jpg
dlls/winspool.drv/En.rc: LTEXT "&Output File Name:", -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/Pl.rc: LTEXT "&Nazwa pliku do ktrego ma by zapisany wydruk:", -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/No.rc: LTEXT "&Ut-fil:", -1, 7, 13, 194, 13, WS_VISIBLE
This one does not generate a fake dll so I did not check it out.
So the situation is not so good.
2010/7/2 Francois Gouget fgouget@free.fr:
As expected Wallon and Finnish are truncated: http://fgouget.free.fr/tmp/reshack/comdlg32_Wa.jpg http://fgouget.free.fr/tmp/reshack/comdlg32_Fi.jpg
I wonder how we will handle these cases once we switch to using PO files. A more generic approach will surely be needed, so that dialogs are resized to fit long data.
Octavian
-
Dmitry Timoshkov -
Francois Gouget -
Frédéric Delanoy -
James McKenzie -
Michael Stefaniuc -
Nikolay Sivov -
Octavian Voicu -
Paul Vriens