wine-devel February 2012

wine-devel@winehq.org

77 participants
169 discussions

Re: po: zh_TW translation updates
by Francois Gouget 28 Feb '12

28 Feb '12

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 "";

2 2

Translators wanted!
by Francois Gouget 28 Feb '12

28 Feb '12

I feel that we should put out a call for translators to the wider community. In preparation for that I updated the Wiki's Translating page and added a winepo script to help translators who don't want to check out the whole Wine source: http://wiki.winehq.org/Translating Here's the proposed news message for the website: > Translators wanted! > > Wine is looking for translators for the 1.4 release! > > Wine's translation <a href="http://fgouget.free.fr/wine-po/">status > page</a> shows only 12 complete translations. We'd like to do better > for 1.4. > > Luckily, starting with 1.4 Wine uses PO files, thus making > translations easier than ever before. So check out how to <a > href="http://wiki.winehq.org/Translating">get started</a> and help us > make Wine usable in your country. And here is the proposed wine-users message: > Wine 1.4 is making good progress. Unfortunately we still have a lot of > translations that are quite incomplete and have no active translators, > thus making Wine unusable in many countries. You track progress on > this page: > > http://fgouget.free.fr/wine-po/ > > As you can see we currently have 12 pretty complete translations and 5 > others that are advanced too. But that still leaves 25 languages > without much, not counting those that are not in the list. This page > also lists some suspected issues that would make easy targets for a > translator short on time. > > The good news is that Wine now uses standard PO files for localization > which makes translation easier than ever before. You even get to > choose between working straight on Wine's source or just editing the > one PO file for your language. So check out the instructions below and > make Wine usable for users in your country! > > http://wiki.winehq.org/Translating Of course if you can help translating Wine, you can also consider this your call to action<g>. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

12 29

Re: po: zh_TW translation updates
by Franklin Weng 28 Feb '12

28 Feb '12

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. > > > >

1 0

Re: msvcrt/file.c: file mode T (temporary file) (try 3)
by Frédéric Delanoy 28 Feb '12

28 Feb '12

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

1 0

Re: Testbot and changes to multiple tests
by Joerg-Cyril.Hoehle＠t-systems.com 27 Feb '12

27 Feb '12

Stefan Dösinger wrote: >When I manually submit a patch to the Wine testbot, it refuses to test it if >the patch changes multiple tests. I know that and live with it as follows: - I usually keep changes to separate tests as distinct commits in my git, so I can send them separately to testbot. I merge them just prior to submission to wine-patches. - Alternatively, I edit the patch file in an editor and change it so that only one test file is modified, then edit again, saving the second test. >Why are they refused when I submit them via the testbot web interface? Perhaps to keep the web interface clean? (e.g. page 3 where it's asking you for the command line arguments) Regards, Jörg Höhle

1 0

Re: po: zh_TW translation updates
by Francois Gouget 27 Feb '12

27 Feb '12

It's great seeing lots of progress being made on the Taiwanese translation. There are a few changes that look a bit strange to me though: msgid "Theme files (*.msstyles; *.theme)" -msgstr "�Ѿ��}�n�� (*.msstyles��*.theme)" +msgstr "�Ѿ��}�n�� (*.msstyles; *.theme)" msgid "TypeLib files (*.tlb; *.olb; *.dll; *.ocx; *.exe)" -msgstr "TypeLib �n�� (*.tlb��*.olb��*.dll��*.ocx��*.exe)" +msgstr "TypeLib �n�� (*.tlb;*.olb;*.dll;*.ocx;*.exe)" So half width semicolons seem to be preferred to full width ones which is fine to me. But in the first patch it's followed by a space, like in English, and not in the second one which seems inconsistent. msgid "Wine Programs (*.exe; *.exe.so)" -msgstr "Wine ��ʽ (*.exe��*.exe.so)" +msgstr "Wine ��ʽ (*.exe,*.exe.so)" Here the semicolon was replaced by a comma (and no space), which is probably wrong. msgid "Programs (*.exe)" -msgstr "��ʽ (*.exe)" +msgstr "��ʽ(*.exe) " The previous changes all preserved the space before the opening parenthesis. If I add the fact that this introduces a space after the closing parenthesis I'd guess this was unintentional. msgid "Printer files (*.prn)" -msgstr "��ӡ�n�� (*.prn)" +msgstr "��ӡ�n�� (*.PRN)" All other strings of this type use lower case for the extension so I'm not sure about this change. +#, fuzzy msgid "The device door is open.\n" -msgstr "" +msgstr "ӡ��C�w�Ǵ��_��; ��\n" +#, fuzzy msgid "Connection unavailable.\n" -msgstr "" +msgstr "��; ��\n" The combination of the semicolon and full width full stop seems wrong. I suspect the fuzzy translations were from the printer common dialog English strings that ended in a semicolon which escaped removal. msgid "" "This program is free software; you can redistribute it and/or modify it " "under the terms of the GNU Lesser General Public License as published by the " "Free Software Foundation; either version 2.1 of the License, or (at your " "option) any later version." msgstr "" "�@��ʽ��ܛ�w�o��\n" "��ܛ�w�� GNU LGPL 2.1\n" "��°��S�ɗl��޸ĺ��\n" "ɢ��@��ʽ��" This string is not supposed to be explicitly wrapped. Is the wrapping made necessary for Taiwanese because of a Wine bug? msgid "Finished searching the document." -msgstr "�n��ь��Y��" +msgstr "�n��ҽY��." msgid "Failed to load the RichEdit library." -msgstr "RichEdit �d��ʧ��" +msgstr "RichEdit �b�dʧ��." Everywhere else full width full stops are used so this change looks strange to me. msgid "Overwrite %1? (Yes|No|All)\n" -msgstr "" +msgstr "�Ƿ��w %1�� ǣ��ȫ��ǣ�\n" Note that in English the 'Yes' implies one should use the 'Y' key, etc. So this set of strings is tied to the following translations: msgctxt "Yes key" msgid "Y" msgstr "" msgctxt "No key" msgid "N" msgstr "" msgctxt "All key" msgid "A" msgstr "" So depending on the keyboard layout it may be necessary to do something like '��(Y)��(N)��ȫ��(A)��' There's another translation which works the same way, look for "(F - File, D - Directory)" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

4 5

Re: msvcrt/file.c: file mode T (temporary file) (try 3)
by Marvin 27 Feb '12

27 Feb '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17117 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2KPROSP4 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WXPPROSP3 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K3R2SESP2 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WVISTAADM (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K8SE (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PRO (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed.

1 0

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.
by Alexandre Julliard 27 Feb '12

27 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1549,11 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status) > + { > + if (wm) free_modref( wm ); > + else if (module) NtUnmapViewOfSection( NtCurrentProcess(), module ); > + } I don't see any evidence that you are addressing the issues that caused us to not do that in the first place. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: dsound: Small fixes to IDirectSoundCaptureBuffer
by Andrew Eikum 27 Feb '12

27 Feb '12

This patch looks sane and fixes the tests on my machine, but causes no changes to dsound capture behavior in Audacity. I don't have much of an opinion on if it should go in for 1.4. On Tue, Feb 21, 2012 at 05:33:35PM +0100, Maarten Lankhorst wrote: > --- > I suspect a lot more AUDCLNT_E_* calls will have to be mapped > correctly, but at least this is enough to pass the dsound:capture > tests again on wine. > > dlls/dsound/capture.c | 8 +++++--- > dlls/dsound/tests/capture.c | 24 +++++++++++++++--------- > 2 files changed, 20 insertions(+), 12 deletions(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 90cddb7..7ceddfc 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -456,13 +456,14 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > > EnterCriticalSection(&(This->device->lock)); > > - This->flags = dwFlags; > - TRACE("old This->device->state=%s\n",captureStateString[This->device->state]); > if (This->device->state == STATE_STOPPED) > This->device->state = STATE_STARTING; > else if (This->device->state == STATE_STOPPING) > This->device->state = STATE_CAPTURING; > + else > + goto out; > TRACE("new This->device->state=%s\n",captureStateString[This->device->state]); > + This->flags = dwFlags; > > if (This->device->buffer) > FillMemory(This->device->buffer, This->device->buflen, (This->device->pwfx->wBitsPerSample == 8) ? 128 : 0); > @@ -474,6 +475,7 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > return hres; > } > > +out: > LeaveCriticalSection(&This->device->lock); > > TRACE("returning DS_OK\n"); > @@ -705,7 +707,7 @@ static HRESULT IDirectSoundCaptureBufferImpl_Create( > HeapFree(GetProcessHeap(), 0, This->pdscbd); > This->device->capture_buffer = 0; > HeapFree( GetProcessHeap(), 0, This ); > - return err; > + return err == AUDCLNT_E_UNSUPPORTED_FORMAT ? DSERR_BADFORMAT : err; > } > > err = IAudioClient_GetService(device->client, &IID_IAudioCaptureClient, > diff --git a/dlls/dsound/tests/capture.c b/dlls/dsound/tests/capture.c > index 96fb417..2040f3f 100644 > --- a/dlls/dsound/tests/capture.c > +++ b/dlls/dsound/tests/capture.c > @@ -393,15 +393,18 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > ok(ref==0,"IDirectSoundNotify_Release(): has %d references, should have " > "0\n",ref); > > - if (record) { > - rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Start(dscbo,0); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > > - rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > - ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > - "GetStatus: bad status: %x\n",status); > + rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > + ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > + "GetStatus: bad status: %x\n",status); > > + if (record) { > /* wait for the notifications */ > for (i = 0; i < (NOTIFICATIONS * 2); i++) { > rc=WaitForMultipleObjects(NOTIFICATIONS,state.event,FALSE,3000); > @@ -416,9 +419,12 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > break; > } > > - rc=IDirectSoundCaptureBuffer_Stop(dscbo); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > > static BOOL WINAPI dscenum_callback(LPGUID lpGuid, LPCSTR lpcstrDescription, > -- > 1.7.7.6 > > > > >

1 0

Re: ntdll: Fix the file mapping view leak in the case of module loading failure.
by Alexandre Julliard 27 Feb '12

27 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1548,8 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status && module) > + NtUnmapViewOfSection( NtCurrentProcess(), module ); It doesn't make sense to free the module as long as we don't free the associated modref. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
2
3
4
5
6
7
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2012