February 2012 - Wine-Devel - list.winehq.org

Re: po: zh_TW translation updates

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > that aside, I think you are quite wrong in trying to "improve user > experience". That's a matter of opinion - and unfortunately, I have > already pointed out, some of the changes are just opinions, and > therefore subject to churns - i.e. some will disagree and want the > older version of a translation of a particular phrase back, etc. I don't have an opinion on the quality of the Taiwanese translation besides the typography aspects for the simple that I don't speak that language. So I'm making no judgement on it and will let Taiwanese translators hash it out. All I want to make clear is that blindly copying Windows' strings is not the wrong approach and not acceptable (and that's true for all languages). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

Feb. 28, 2012

Re: Translators wanted!

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > > Do not do that. That would be copyright infrigement. That's > > not what we > > want. This would get your contributions removed from Wine. > > claiming copyright on short phrases like 'loading dlls failed' (in > whatever language) seems very far-fetched. Claiming copyright on a set of such sentences isn't. Not all books are exclusively composed of paragraph long sentences... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

Feb. 28, 2012

Re: po: zh_TW translation updates

by Franklin Weng

Hi, I rechecked the translation with old zh_TW.po file. I used Kompare and picked the better one for each entry. I hope that the new patch file is okay and acceptable. I'll post the new patch again later. BTW, the Chinese name (used in Taiwan) of Free Software Foundation is "自由軟體基金會", that's correct. Thanks, Franklin 2012/2/27 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > --- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > >> Patches are posted to wine-patches(a)winehq.org: >> http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html > > A quick look at it (it is a few hundred k) - says a few of the problems I saw and suspected: > > - some of the changes are not improvements/corrections but just opinionated changes > > - some changes are wrong (i.e. the older version is more correct/natural and the change makes it worse, not better). > > - some of the changes are over-eager: i.e. it "improves" on windows and tried to be more user-friendly, but not exactly how windows does it. > > I think there should be a notes on the translation FAQ: one is not looking to be "better than" windows, but bug-for-bug-compatible. Therefore translation is preferably what regional/localized windows (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is easy enough to do a few screenshots of localized windows (be in traditional or simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to most of these translation strings: what localized windows (some version) does. It is not up to individual or group opinions, really. I mean, public libraries, etc have windows in the far east, there is no excuse to be wrong, or on the opposite extreme, "try to improve on windows", even if one does not want to get one's hand dirty and own a windows box. > > > >

Feb. 28, 2012

Re: msvcrt/file.c: file mode T (temporary file) (try 3)

by Frédéric Delanoy

On Mon, Feb 27, 2012 at 11:23, Robert van Herk <mijnspamboxje(a)hotmail.com> wrote: >> So what actually prevents you from properly implementing this? Especially >> that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY >> >> Vitaliy. > > I wrote a new version that maps > 'D' -> MSVCRT__O_TEMPORARY, and > 'T' -> MSVCRT__O_SHORT_LIVED | MSVCRT__O_TEMPORARY > > I deliberately included MSVCRT__O_TEMPORARY in 'T': on Windows, when a file > is opened in 'T' mode, a subsequent call to GetFileAttributes(tempfile) show > that the FILE_ATTRIBUTE_TEMPORARY flag is set, so this seemed like to most > sensible thing to do. > > I updated the conformance test such that it checks that the file is actually > deleted after fclose. > > Kind regards, > Robert van Herk You may already be aware of this, but you can request a testbot account to check your patches before submission to wine-patches. See http://testbot.winehq.org/ Frédéric

Feb. 28, 2012

Re: Web based translation tool

by Yaron Shahrabani

Hi guys! If I understand correctly the wanted solution is the translation attribution will be per string basis meaning that we can attribute a certain author to a string. The only system I'm aware of that is capable of such thing is TranslateWiki, which is a little overkill because we will have to use a full wiki system in order to implement gettext (which can be done using a much less sophisticated system). Since the Wine project already has a Wiki, maybe we can utilize this wiki in order to install TranslateWiki. There are several advantages: 1. The strings are saved just like wiki pages meaning that there's a full history and diff of all strings including dates and authors. 2. The statistics are great (The current statistics is nice as well but contains less info). 3. It's a full wiki system (Both advantage and disadvantage). None of the other systems can attribute a certain translation to a certain author AFAICT. Kind regards, Yaron Shahrabani <Hebrew translator> 2012/2/27 Miroslav Suchý <msuchy(a)redhat.com> > Hi, > I just read: > http://www.winehq.org/news/**2012022001<http://www.winehq.org/news/2012022001> > and then > http://wiki.winehq.org/**Translating <http://wiki.winehq.org/Translating> > especially: > >> The Wine project would be very interested in making its PO files >> available on web-based community translations systems such as Pootle or >> Launchpad. Our hope is that this would make translating Wine even easier >> and engage new translators. >> >> The reason why it has not happened yet is that all Wine contributions, >> including for translations, must be attributable to a specific author and >> that these tools don't make that possible yet. For more details see the >> wine-devel discussion here and here. Any contributions that would solve >> this issue would be very welcome. >> > > which refer: > http://www.winehq.org/**pipermail/wine-devel/2012-**January/093908.html<http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html> > > I would like to point you to: > https://www.transifex.net/ > which can do the tracking. > > Latest version is probably not what you want, because it just add at the > top of the file: > # Translators: > # Martin Minar <skulliq(a)gmail.com>, 2011. > # Milan Kerslager <kerslage(a)linux.cz>, 2002, 2007. > # Miloslav Trmac <mitr(a)volny.cz>, 2002. > # Miroslav Suchý <msuchy(a)redhat.com>, 2011. > msgid "" > msgstr "" > "Project-Id-Version: Spacewalk\n" > "Report-Msgid-Bugs-To: \n" > "POT-Creation-Date: 2011-12-21 13:07+0100\n" > "PO-Revision-Date: 2011-12-14 09:21+0000\n" > "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com>\n" > "Language-Team: Czech (http://www.transifex.net/** > projects/p/fedora/team/cs/<http://www.transifex.net/projects/p/fedora/team/cs/> > )\n > > So you had overview of contributors, but you could not tell which one > contributor done which string. > > But version 0.7 (IIRC) sent each contribution immediately to git. Under > login (and email) of that contributor. That contributor was "Author" and > commiter was some transifex user. So this way you allow git commit access > to those contributors directly to git, but since it goes via that web > interface, they could commit only to /po/ directory and even only to > language, for which they had been granted. > > You can download it here: > http://trac.transifex.org/**files/ <http://trac.transifex.org/files/> > and setup your own instance. > > If is sufficient for you only tracking name of contributors, you can use > that hosted solution at: https://www.transifex.net/ > > > -- > Miroslav Suchy > Red Hat Satellite Engineering > > >

Feb. 28, 2012

Re: po: zh_TW translation updates

by Hin-Tak Leung

--- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > On Mon, 27 Feb 2012, Hin-Tak Leung > wrote: > [...] > > - some of the changes are over-eager: i.e. it > "improves" on windows > > and tried to be more user-friendly, but not exactly how > windows does > > it. > > > > I think there should be a notes on the translation FAQ: > one is not > > looking to be "better than" windows, but > bug-for-bug-compatible. > > Therefore translation is preferably what > regional/localized windows > > (whatever version) does. > > > > 20% of the world's population is Chinese, I am sure it > is easy enough > > to do a few screenshots of localized windows (be in > traditional or > > simplied) and show how those behave. > > > > There is a definitive answer (or "definition answers") > to most of > > these translation strings: what localized windows (some > version) does. > > It is not up to individual or group opinions, really. I > mean, public > > libraries, etc have windows in the far east, there is > no excuse to be > > wrong, or on the opposite extreme, "try to improve on > windows", even > > if one does not want to get one's hand dirty and own a > windows box. > > The dialog labels and error messages are an area where we > don't need to > and don't want to be word for word identical to Windows. > > We should definitely follow the Windows User Experience > Interaction > Guidelines: > http://msdn.microsoft.com/en-us/library/aa511258.aspx > > The Windows GUI is certainly be a valuable resource to > determine which > terms the users are going to be familiar with (e.g. will > they more > readily understand 'directory' or 'folder'). That said Wine > runs on > Linux and Mac OS X so Wine's users will likely be somewhat > accustomed to > the terms used by these platforms too. > > But in any case blindly copying all the strings from the > Windows GUI > would be a very bad idea. but wine is supposed to be bug-for-bug compatible with windows, (just as a joke, or not), surely that includes poor user experience? :-). that aside, I think you are quite wrong in trying to "improve user experience". That's a matter of opinion - and unfortunately, I have already pointed out, some of the changes are just opinions, and therefore subject to churns - i.e. some will disagree and want the older version of a translation of a particular phrase back, etc.

Feb. 27, 2012

Re: Translators wanted!

by Hin-Tak Leung

--- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > On Mon, 27 Feb 2012, Hin-Tak Leung > wrote: > [...] > > One should *not* be creative and does one's own thing - > the localized > > message files should be (some version of) what > localized windows > > shows. Anything else is wrong. > > Do not do that. That would be copyright infrigement. That's > not what we > want. This would get your contributions removed from Wine. claiming copyright on short phrases like 'loading dlls failed' (in whatever language) seems very far-fetched.

Feb. 27, 2012

Re: Major mmdevapi and winmm audio bugs

by Maarten Lankhorst

Hey Joerg, Op 27-02-12 19:22, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote (partly in a former thread): > >>> R. thread priority -- no "Pro Audio" / Real-Time priority >> Not going to happen, ever. AJ nuked all my attempts at it, >> [...] >> Or just fix things properly and use rtkit for time critical threads > and now: >> I would say using rtkit for setting threads to realtime would be an aid for this. > I can understand AJ's reluctance to RT code in Wine. I wouldn't feel > comfortable either. I believe few people realize that RT is a gifted > gift. Bear in mind that RT processes work at a priority above any > root or user process. Do something wrong there, consume 100% CPU and > you can press the single core machine's power down button. I would > not accept RT code in a system without a very careful code review and > think twice about the consequences, and require a design that keeps > the RT part of the app as small as possible, better separated. > > OTOH, RT is the means to provide reliable ticks, and that's why PA as > a sound server wants that. Now one can argue that Wine's mmdevapi > plays sound server for all w32 apps, so it has the same needs. Agreed, I've tried to keep it as small as possible for the thread itself, the mainloop thread calls very few functions, I need to add a bit more, but the only source of problems could come from the pulseaudio lib itself. At this point my winepulse driver is very reliable for rendering, and capture should be the same once I add the queue stuff, it would also be the only driver to actually pass the tests. For capture I plan to just add 2 queues, one for readable packets, and one for packets that can be filled for reading. With that approach I should be able to pass all tests in the most efficient way while keeping the metadata mmdevapi adds for capture. >> I'm just using a simple mainloop thread > That's my plan for past 1.4 too. Get rid of CreateTimerQueue as > callback source in mmdevapi, use a thread for the feeder and poll() to > wait 10ms, like all devices used to do. > I believe that's too big a change for code freeze. > > W.r.t. to 1.4.0, I believe the following path should be taken: > - Write CreateTimerQueue tests to verify whether native behaves like: > a) sleep(Xms) /* what Wine does now */ or > b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ > - If b), fix CreateTimerQueue. > - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi > and something else must be sought... Even if so, it is unneeded for the pulse driver, I'm using the auto timing update feature and the callback for when rendering is not running. When the buffer is not underflowed, I'm using the write callback to signal more data is available. Timerqueue would be a lie, the driver should schedule when data can actually be written and not based purely on ticks. Pulseaudio allows this and I'm using this feature in my driver. It passes all the render tests now except the volume related ones (they're a reminder, and a nop on other drivers anyhow), and I'm working to complete capture in a similar fashion as well. I believe the event should be triggered when there is actual data available, at least that's how I understood the event is supposed to work. Doing it based on a timer that isn't tied to the state in any way feels wrong. Having 2 threads for pulse feels wrong too, especially since it can be done with just using the one pulse provides, because you can set callbacks for when more data can be read or written. ~Maarten

Feb. 27, 2012

Re: Translators wanted!

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > One should *not* be creative and does one's own thing - the localized > message files should be (some version of) what localized windows > shows. Anything else is wrong. Do not do that. That would be copyright infrigement. That's not what we want. This would get your contributions removed from Wine. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Feb. 27, 2012

Re: po: zh_TW translation updates

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > - some of the changes are over-eager: i.e. it "improves" on windows > and tried to be more user-friendly, but not exactly how windows does > it. > > I think there should be a notes on the translation FAQ: one is not > looking to be "better than" windows, but bug-for-bug-compatible. > Therefore translation is preferably what regional/localized windows > (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is easy enough > to do a few screenshots of localized windows (be in traditional or > simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to most of > these translation strings: what localized windows (some version) does. > It is not up to individual or group opinions, really. I mean, public > libraries, etc have windows in the far east, there is no excuse to be > wrong, or on the opposite extreme, "try to improve on windows", even > if one does not want to get one's hand dirty and own a windows box. The dialog labels and error messages are an area where we don't need to and don't want to be word for word identical to Windows. We should definitely follow the Windows User Experience Interaction Guidelines: http://msdn.microsoft.com/en-us/library/aa511258.aspx The Windows GUI is certainly be a valuable resource to determine which terms the users are going to be familiar with (e.g. will they more readily understand 'directory' or 'folder'). That said Wine runs on Linux and Mac OS X so Wine's users will likely be somewhat accustomed to the terms used by these platforms too. But in any case blindly copying all the strings from the Windows GUI would be a very bad idea. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

Feb. 27, 2012