April 2014 - Wine-Devel - list.winehq.org

Re: loader: add HKLM\\Software\\Microsoft\\Multimedia\\WMPlayer\\Extensions key

by Jacek Caban

Hi Austin, On 04/07/14 09:32, Austin English wrote: > diff --git a/loader/wine.inf.in b/loader/wine.inf.in > index 1f08d2e..8200d41 100644 > --- a/loader/wine.inf.in > +++ b/loader/wine.inf.in > @@ -662,6 +662,8 @@ HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-99 > HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Locale",2,"*" > HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Version",2,"4,74,9273,0" > > +; Windows Media Player > +HKLM,SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions,,16 This could probably go to dlls/wmp/wmp.rgs. Jacek

April 7, 2014

Re: [2/2] include/vfw.h: Replace handmade COM method macros by widl generated ones (including inline wrappers).

by Henri Verbeet

On 7 April 2014 09:43, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Actually, Henri, Stefan, what was decided for DirectX headers in that > regard? Leave as it is, switch to idls eventually, something else? > We'd like to generate them from IDL eventually, but I don't think anyone is currently actively working on that.

April 7, 2014

Re: [PATCH 2/2] dwrite: Store text format properties

by Nikolay Sivov

On 4/7/2014 10:39, Dmitry Timoshkov wrote: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>>> +static HRESULT WINAPI dwritetextformat_SetLineSpacing(IDWriteTextFormat *iface, DWRITE_LINE_SPACING_METHOD method, >>>> + FLOAT spacing, FLOAT baseline) >>>> { >>>> struct dwrite_textformat *This = impl_from_IDWriteTextFormat(iface); >>>> - FIXME("(%p)->(%d %f %f): stub\n", This, spacing, line_spacing, baseline); >>>> - return E_NOTIMPL; >>>> + TRACE("(%p)->(%d %f %f)\n", This, method, spacing, baseline); >>>> + This->format.spacingmethod = method; >>>> + This->format.spacing = spacing; >>>> + This->format.baseline = baseline; >>>> + return S_OK; >>>> } >>> Probably all the format properties setters should handle invalid enum or >>> negative floating point arguments some way. >>> >> It's too early to care about that at this point. > I'm afraid that it will be too late when some application sets invalid value > and that would lead to weird rendering results for unknown reason. For now I only need it to succeed, once it starts to draw something this will be revised or will be redone if needed.

April 7, 2014

Re: [2/2] include/vfw.h: Replace handmade COM method macros by widl generated ones (including inline wrappers).

by Nikolay Sivov

On 4/7/2014 11:32, Dmitry Timoshkov wrote: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> I think the idea was to have a proper idl file eventually. > Amount of autogenerated code in that file is relatively small (actually > that's what I just have submitted) and it doesn't worth the trouble to > create an idl IMHO. Besides PSDK doesn't have it autogenerated either. The point is to make it autogenerated. I know that PSDK doesn't do that in many places, we don't necessary have to follow. Actually, Henri, Stefan, what was decided for DirectX headers in that regard? Leave as it is, switch to idls eventually, something else?

April 7, 2014

Re: [2/2] include/vfw.h: Replace handmade COM method macros by widl generated ones (including inline wrappers).

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > I think the idea was to have a proper idl file eventually. Amount of autogenerated code in that file is relatively small (actually that's what I just have submitted) and it doesn't worth the trouble to create an idl IMHO. Besides PSDK doesn't have it autogenerated either. -- Dmitry.

April 7, 2014

Re: [2/2] include/vfw.h: Replace handmade COM method macros by widl generated ones (including inline wrappers).

by Nikolay Sivov

I think the idea was to have a proper idl file eventually.

April 7, 2014

Re: [PATCH 2/2] dwrite: Store text format properties

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> +static HRESULT WINAPI dwritetextformat_SetLineSpacing(IDWriteTextFormat *iface, DWRITE_LINE_SPACING_METHOD method, > >> + FLOAT spacing, FLOAT baseline) > >> { > >> struct dwrite_textformat *This = impl_from_IDWriteTextFormat(iface); > >> - FIXME("(%p)->(%d %f %f): stub\n", This, spacing, line_spacing, baseline); > >> - return E_NOTIMPL; > >> + TRACE("(%p)->(%d %f %f)\n", This, method, spacing, baseline); > >> + This->format.spacingmethod = method; > >> + This->format.spacing = spacing; > >> + This->format.baseline = baseline; > >> + return S_OK; > >> } > > Probably all the format properties setters should handle invalid enum or > > negative floating point arguments some way. > > > It's too early to care about that at this point. I'm afraid that it will be too late when some application sets invalid value and that would lead to weird rendering results for unknown reason. -- Dmitry.

April 7, 2014

Re: [PATCH 2/2] dwrite: Store text format properties

by Nikolay Sivov

On 4/7/2014 09:29, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +static HRESULT WINAPI dwritetextformat_SetLineSpacing(IDWriteTextFormat *iface, DWRITE_LINE_SPACING_METHOD method, >> + FLOAT spacing, FLOAT baseline) >> { >> struct dwrite_textformat *This = impl_from_IDWriteTextFormat(iface); >> - FIXME("(%p)->(%d %f %f): stub\n", This, spacing, line_spacing, baseline); >> - return E_NOTIMPL; >> + TRACE("(%p)->(%d %f %f)\n", This, method, spacing, baseline); >> + This->format.spacingmethod = method; >> + This->format.spacing = spacing; >> + This->format.baseline = baseline; >> + return S_OK; >> } > Probably all the format properties setters should handle invalid enum or > negative floating point arguments some way. > It's too early to care about that at this point.

April 7, 2014

Re: [PATCH 2/2] dwrite: Store text format properties

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI dwritetextformat_SetLineSpacing(IDWriteTextFormat *iface, DWRITE_LINE_SPACING_METHOD method, > + FLOAT spacing, FLOAT baseline) > { > struct dwrite_textformat *This = impl_from_IDWriteTextFormat(iface); > - FIXME("(%p)->(%d %f %f): stub\n", This, spacing, line_spacing, baseline); > - return E_NOTIMPL; > + TRACE("(%p)->(%d %f %f)\n", This, method, spacing, baseline); > + This->format.spacingmethod = method; > + This->format.spacing = spacing; > + This->format.baseline = baseline; > + return S_OK; > } Probably all the format properties setters should handle invalid enum or negative floating point arguments some way. -- Dmitry.

April 7, 2014

Re: mshtml: Added IHTMLTable::bgColor property implementation.

by Nikolay Sivov

On 4/6/2014 18:48, Zhenbo Li wrote: > try 2: > Don't free a string too early. > > --- > dlls/mshtml/htmltable.c | 41 +++++++++++++++++++++++++++++++++++++---- > dlls/mshtml/tests/dom.c | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 72 insertions(+), 4 deletions(-) > Also please check for variant_to_nscolor() return value.

April 7, 2014

Re: [3/5] ntdll: Implement RtlInstallFunctionTableCallback on x86_64.

by Sebastian Lackner

Hi, Am 07.04.2014 03:08, schrieb Dmitry Timoshkov: > Sebastian Lackner <sebastian(a)fds-team.de> wrote: > >> +BOOLEAN CDECL RtlInstallFunctionTableCallback( DWORD64 table, DWORD64 base, DWORD length, >> + PGET_RUNTIME_FUNCTION_CALLBACK callback, PVOID context, PCWSTR dll ) >> +{ > spec entry doesn't match the implementation. Probably it should be > (int64 int64 long ptr ptr wstr) RtlInstallFunctionTableCallback on ARM takes regular DWORDs as arguments. My idea was to use the same trick as for RtlAddFunctionTable, to make it possible to use the same spec file entry for both x86_64 and for ARM (if someone else implements the function later). If int64 != long on 64-bit systems then this entry would also be invalid: declaration: BOOLEAN CDECL RtlAddFunctionTable( RUNTIME_FUNCTION *table, DWORD count, DWORD64 addr ) specfile: @ cdecl -arch=arm,x86_64 RtlAddFunctionTable(ptr long long) But I have to agree for the ptr -> wstr replacement, which is probably a bit better, although I haven't seen any applications yet that use it (they all just pass NULL pointers). I'll wait for some more feedback and resubmit the patch if this is the only change. > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms680595%28v=vs.85%… > claims that RtlInstallFunctionTableCallback is WINAPI, not CDECL, which > one is correct? > Based on winnt.h on my Windows 8 machine with it is __cdecl, so i guess MSDN is wrong - but it wouldn't matter anyway because there is only one calling convention on x86_64, see: http://source.winehq.org/source/include/windef.h#L67 Regards, Sebastian

April 7, 2014

Re: [3/5] ntdll: Implement RtlInstallFunctionTableCallback on x86_64.

by Dmitry Timoshkov

Sebastian Lackner <sebastian(a)fds-team.de> wrote: > +BOOLEAN CDECL RtlInstallFunctionTableCallback( DWORD64 table, DWORD64 base, DWORD length, > + PGET_RUNTIME_FUNCTION_CALLBACK callback, PVOID context, PCWSTR dll ) > +{ http://msdn.microsoft.com/en-us/library/windows/desktop/ms680595%28v=vs.85%… claims that RtlInstallFunctionTableCallback is WINAPI, not CDECL, which one is correct? -- Dmitry.

April 7, 2014

Re: [3/5] ntdll: Implement RtlInstallFunctionTableCallback on x86_64.

by Dmitry Timoshkov

Sebastian Lackner <sebastian(a)fds-team.de> wrote: > +@ cdecl -arch=x86_64 RtlInstallFunctionTableCallback(long long long ptr ptr ptr) ... > +BOOLEAN CDECL RtlInstallFunctionTableCallback( DWORD64 table, DWORD64 base, DWORD length, > + PGET_RUNTIME_FUNCTION_CALLBACK callback, PVOID context, PCWSTR dll ) spec entry doesn't match the implementation. Probably it should be (int64 int64 long ptr ptr wstr) -- Dmitry.

April 7, 2014

Re: [PATCH] ddraw: add dsurface dimension tests, try 8

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-04 13:57, schrieb Patrick Rudolph: > + static struct > + { > + const char *name; > + DDPIXELFORMAT fmt; > + } > + formats[] = You can make this const. > + /* 6: Test maximum surface height */ > + {DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT, DDSCAPS_OFFSCREENPLAIN, 1, 0x10000, DDERR_INVALIDPARAMS}, > + /* 7: Test maximum surface width */ > + {DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT, DDSCAPS_OFFSCREENPLAIN, 0x10000, 1, DDERR_INVALIDPARAMS}, These tests fail on Wine. Please include your patch that introduces the size check in this patch or in a separate patch to apply before this one, or mark them todo_wine. > + /* 8: Test OUTOFVIDEOMEMORY */ > + {DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT, DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, > + 0xffff, 0xffff, DDERR_OUTOFVIDEOMEMORY}, This also fails on Wine. You'll have to move the adapter_adjust_memory() call in dlls/wined3d/resource.c, resource_init() ahead of the memory allocation call. > + /* 9: Test OUTOFMEMORY */ > + {DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT, DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, > + 0xffff, 0xffff, DDERR_OUTOFMEMORY}, This test still fails in 64 bit on my Windows 7 test machine with D3DFMT_P8. The failure happens because CreateSurface succeeds although the test expects it to fail. I'd suggest to remove this test for the same reason as test 10. > + /* does the hardware support videomemory ? */ > + if (!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) > + { > + tests[8].hr = DDERR_NODIRECTDRAWHW; > + } You can remove the curly brackets here. > + for (i = 0; i < sizeof(tests) / sizeof(*tests); i ++) > + { > + if (surface) > + { > + IDirectDrawSurface_Release(surface); > + surface = NULL; > + } > + > + memset(&surfacedesc, 0, sizeof(surfacedesc)); > + surfacedesc.dwSize = sizeof(surfacedesc); > + surfacedesc.dwFlags = tests[i].dwFlags | DDSD_PIXELFORMAT; > + surfacedesc.ddsCaps.dwCaps = tests[i].dwCaps; > + surfacedesc.dwWidth = tests[i].dwWidth; > + surfacedesc.dwHeight = tests[i].dwHeight; > + surfacedesc.ddpfPixelFormat = formats[j].fmt; > + > + hr = IDirectDraw_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(hr == tests[i].hr, "Pixelformat %s, test %d returned %08x\n", formats[j].name, i, hr); > + } Why is the surface release before the create call? You're potentially leaking surfaces here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQdGlAAoJEN0/YqbEcdMwvikP/RT9mO2pARAAfY7DIRuOns3R 8rYw7skxAOwKU12NK42gaSqTjZKoRglpXyYJwD1keq9uRZnk8oAy4yQN7axg3/wq OI8gF6VN9Dlqofq6l4FD8rNC0yBFxxehZkOJXpzGXGisDau3C+pK007+fnwb0zQI IOJ+M/ok+cOvmymbktmrRryVtrttG5Z0EYqpBQw53+ZTKUyu6AhcuoXV5Sf04Jkx SnCHhRn3RLKEMTwc/XT6O5+in89CgIcrMmNWnCk0JrgywNhqOxX4A9HzkHTL3h/n OHR1fJW4SmRDwT4r+nQmOBjIY7tCipv0xK5LTOqbaNCDxTIyZL2AOji5PeR4mZWH iHPOb6826iouxE8P12cLfgueBebhY/lVCmiWwV67K7koFSmYs4MhtR/jdeiuZ8rI jYgta2gNvP8Nk+R+HGxhGg6rrykNBb+lWTI5Ua+QAa7DBdW9uldLH4U+bf6mti90 171NAQA0VTrxV/dnkAxOmZ4jXogWhShrIyElD3PG6ZCxZ6W85/tdLReAyy/+feoQ OS+QdlYDrnYJlW0Bko254YAWJHk5hViy7feDFCHl+FuI/7hN3+UmKvpVloWkD7sh EpRqmAm8GtxAyaPsJtJVkWQ6s3YTkoYIZOSVUbItRWJbQvEfB/DDIYG6lTkGAxS5 cEUsoGMsqQbBK9QZf/s2 =TT3X -----END PGP SIGNATURE-----

April 6, 2014

Re: po: Revise Russian translation

by Nikolay Sivov

On 4/6/2014 19:43, Dmitry Timoshkov wrote: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>> Why for >>> instance in the same translation update "SCANNING... Please Wait" still >>> contains 'пожалуйста' (please) then? There are other occurances of 'please' >>> all over the place, are you suggesting to remove them all as well in >>> the russian translation? >> Not necessary, it's not all-or-nothing rule. Each case should be >> considered separately, for "SCANNING.." one it's better to keep 'please' >> translated, because otherwise it becomes too short and feels incomplete >> (no, same doesn't apply for select a file). > You forgot to add some details, for instance explain why it doen't > apply for 'select a file', but does apply to 'please wait'. I already explained why we don't need it for 'select a file', several times. For "SCANNING.." line, if you're really interested about that one, it's malformed in a first place. Much better translation would be "Подождите, идет сканирование", or something like that, but because of specific format of original string we can't do that without changing original line. We could remove 'please' part from it too, but as I said it will make it unpleasantly short and incomplete.Again that's not a good example to compare to. > > [unrelated speculations are skipped] >

April 6, 2014

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits

by Ken Thomases

On Apr 6, 2014, at 11:04 AM, Daniel Horn wrote: > Thanks for thinking this through. An alternative is using a trylock and assuming a cache miss (or not adding to the cache) if trylock fails. I don't think that's safe with respect to the issue of being suspended and causing deadlock. The try may succeed, in which case you hold the critical section, in which case you should have set the sigmask beforehand, in which case you still incur the syscall expense. (Although I'm still not confident I've completely understood the purpose of blocking signals for the duration of holding that critical section.) -Ken

April 6, 2014

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits

by Daniel Horn

Thanks for thinking this through. An alternative is using a trylock and assuming a cache miss (or not adding to the cache) if trylock fails. That would surely be simpler code. I will benchmark both variants vs the original and let you know my findings - Daniel On Sun, Apr 6, 2014 at 8:47 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Apr 5, 2014, at 8:37 PM, Ken Thomases wrote: >> It might be possible to have a safe, lockless version of get_cached_fd() that sometimes produces a false-negative. Then, if it fails, you'd enter the uninterrupted section and try the reliable version before making the server call. Devising such a scheme and convincing us that it's safe and reliable is the hard part. It might be sufficient put a memory barrier before the lookup of the fd in get_cached_fd() and then something like this at the bottom of that block: >> >> if (interlocked_cmpxchg( &fd_cache[entry][idx].fd, fd + 1, fd + 1) != fd + 1) >> fd = -1; >> >> The idea is to verify that the fd has not been replaced or removed after we fetched it and its properties. > It occurred to me that, for this to work, add_fd_to_cache() has to be changed, too. I think the fd has to be temporarily cleared, then the properties have to be stored, and then the fd can be stored. A write memory barrier is required, but is supplied by interlocked_xchg() which is already used. > So, adding looks like: > clear fd > store properties > store fd > Getting looks like: > get fd > get properties > get fd again and compare > If a valid fd was read and it didn't change between the two points, then you can be sure the properties that you read go with the fd. > -Ken

April 6, 2014

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits

by Ken Thomases

On Apr 5, 2014, at 8:37 PM, Ken Thomases wrote: > It might be possible to have a safe, lockless version of get_cached_fd() that sometimes produces a false-negative. Then, if it fails, you'd enter the uninterrupted section and try the reliable version before making the server call. Devising such a scheme and convincing us that it's safe and reliable is the hard part. It might be sufficient put a memory barrier before the lookup of the fd in get_cached_fd() and then something like this at the bottom of that block: > > if (interlocked_cmpxchg( &fd_cache[entry][idx].fd, fd + 1, fd + 1) != fd + 1) > fd = -1; > > The idea is to verify that the fd has not been replaced or removed after we fetched it and its properties. It occurred to me that, for this to work, add_fd_to_cache() has to be changed, too. I think the fd has to be temporarily cleared, then the properties have to be stored, and then the fd can be stored. A write memory barrier is required, but is supplied by interlocked_xchg() which is already used. So, adding looks like: clear fd store properties store fd Getting looks like: get fd get properties get fd again and compare If a valid fd was read and it didn't change between the two points, then you can be sure the properties that you read go with the fd. -Ken

April 6, 2014

Re: po: Revise Russian translation

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > > Why for > > instance in the same translation update "SCANNING... Please Wait" still > > contains 'пожалуйста' (please) then? There are other occurances of 'please' > > all over the place, are you suggesting to remove them all as well in > > the russian translation? > Not necessary, it's not all-or-nothing rule. Each case should be > considered separately, for "SCANNING.." one it's better to keep 'please' > translated, because otherwise it becomes too short and feels incomplete > (no, same doesn't apply for select a file). You forgot to add some details, for instance explain why it doen't apply for 'select a file', but does apply to 'please wait'. [unrelated speculations are skipped] -- Dmitry.

April 6, 2014

Re: po: Revise Russian translation

by Nikolay Sivov

On 4/6/2014 09:12, Dmitry Timoshkov wrote: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>>>>> Looks good. I especially like changes like these: >>>>>> >>>>>> --- >>>>>> -msgstr "Пожалуйста, выберите файл." >>>>>> +msgstr "Выберите файл." >>>>> No, this doesn't match the original english text. >>>> I matches okay and sounds better. Verb form is already in plural which >>>> makes 'please' redundant. >>> 'Please' is never redundant, please don't invent new rules. Or should I omit >>> 'please' here? >> No, you can't. There's no way to express it in English, don't be silly. >> Suggested form is shorter and has exactly same meaning - politely asks >> to do something. > 'Please select a file' and 'Select a file' have cleary different emotional > meaning both in english and in russian. If you would like to omit 'please' > in russian translations you need to correct english version first. English version is fine, I explained below. > Why for > instance in the same translation update "SCANNING... Please Wait" still > contains 'пожалуйста' (please) then? There are other occurances of 'please' > all over the place, are you suggesting to remove them all as well in > the russian translation? Not necessary, it's not all-or-nothing rule. Each case should be considered separately, for "SCANNING.." one it's better to keep 'please' translated, because otherwise it becomes too short and feels incomplete (no, same doesn't apply for select a file). > What's so special about russian language that it > should sound rude while the original text intentionally has 'please'? I never said it should. It's not something unique to Russian language, French has same thing too - ability to address a single person respectfully with a verb form also used for plural form for you/вы/vous. There's two ways to translate 'select' in imperative way - "выбери" or "выберите". First variant is what you call rude, and I'm not suggesting to use it. Second variant is respectful enough to skip 'please'. >>>>> Some other translations >>>>> don't match either, for instance >>>>> >>>>>> "This large number of copies is not supported by your printer.\n" >>>>>> "Please enter a value between 1 and %d." >>>>>> msgstr "" >>>>>> -"Такое большое количество копий не может быть напечатано вашим принтером.\n" >>>>>> +"Такое большое количество копий не может быть напечатано этим принтером.\n" >>>>>> >>>> What you mean? 'your' translated literally is out of place here. Article >>>> or a possessive pronoun before a noun is not a requirement in Russian, >>>> as I'm sure you know. In this particular phase it would be enough to say >>>> 'не поддерживается принтером'. No need to literally match English variant. >>> 'your printer' and 'this printer' have two distinct and different meanings, >>> please avoid inventing new traslation rules unless you have a degree in this >>> area. >> Could we talk about this particular case instead of making >> generalizations or discussing degrees? Thing is distinction is not >> important here, 'your' exists in English variant because it has to. > If it's not important then there is nothing to discuss and "fix". > > In general it's important IMHO to keep translated text match its english > version as much as possible. One of the reasons is to avoid other translators > from fixing the mismatches, another is to really keep the UI consistent in > different languages. Julius' answer covers that part.

April 6, 2014

Re: po: Revise Russian translation

by Julius Schwartzenberg

Dmitry Timoshkov wrote: > In general it's important IMHO to keep translated text match its english > version as much as possible. One of the reasons is to avoid other translators > from fixing the mismatches, another is to really keep the UI consistent in > different languages. The thing that makes these translations difficult is that this is not so easy when translating Russian into English. A sentence like: "Выберите принтер" could be "Choose your printer" or "Choose a printer" in English, depending on the context. This is partially a peculiarity of English (and other Western-European languages) and partially because in Russian people tend to use possessive pronouns less in general. If you would always try to keep exact translations, it would mean that software which is originally Russian would likely have different texts than software which is originally in English and then translated to Russian. I think Nikolay's idea is to avoid this difference. The other way around, you can translate "мне нравится" to English every time as "for me it is nice" or "by me it is liked", but English speakers would only consider "I like" a proper translation. I also understand the reasons why one would still try to maintain the original as much as possible however, so I would try to find a common guideline on how to deal with this for the Russian translation (or for all Slavic translations). Best regards, Julius

April 6, 2014

Re: po: Revise Russian translation

by Aurimas Fišeras

2014.04.06 05:55, Dmitry Timoshkov rašė: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>>> Looks good. I especially like changes like these: >>>> >>>> --- >>>> -msgstr "Пожалуйста, выберите файл." >>>> +msgstr "Выберите файл." >>> No, this doesn't match the original english text. >> I matches okay and sounds better. Verb form is already in plural which >> makes 'please' redundant. > > 'Please' is never redundant, please don't invent new rules. Or should I omit > 'please' here? Hello, according to the Microsoft Russian Style Guide [1] (p. 41): "The word "please" is often used in English sentences. In Russian equivalents the literate translation "пожалуйста" is out of place. Do not overuse it." [1] http://www.microsoft.com/Language/en-US/StyleGuides.aspx

April 6, 2014

Re: po: Revise Russian translation

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>>> Looks good. I especially like changes like these: > >>>> > >>>> --- > >>>> -msgstr "Пожалуйста, выберите файл." > >>>> +msgstr "Выберите файл." > >>> No, this doesn't match the original english text. > >> I matches okay and sounds better. Verb form is already in plural which > >> makes 'please' redundant. > > 'Please' is never redundant, please don't invent new rules. Or should I omit > > 'please' here? > No, you can't. There's no way to express it in English, don't be silly. > Suggested form is shorter and has exactly same meaning - politely asks > to do something. 'Please select a file' and 'Select a file' have cleary different emotional meaning both in english and in russian. If you would like to omit 'please' in russian translations you need to correct english version first. Why for instance in the same translation update "SCANNING... Please Wait" still contains 'пожалуйста' (please) then? There are other occurances of 'please' all over the place, are you suggesting to remove them all as well in the russian translation? What's so special about russian language that it should sound rude while the original text intentionally has 'please'? > >> Same thing as for 'Вы' garbage when used to > >> address one person. > > Oh, probably one should ask how well did you learn Russian in school. > You sure you got what I mean? I think I did, you could always elaborate of course. > >>> Some other translations > >>> don't match either, for instance > >>> > >>>> "This large number of copies is not supported by your printer.\n" > >>>> "Please enter a value between 1 and %d." > >>>> msgstr "" > >>>> -"Такое большое количество копий не может быть напечатано вашим принтером.\n" > >>>> +"Такое большое количество копий не может быть напечатано этим принтером.\n" > >>>> > >> What you mean? 'your' translated literally is out of place here. Article > >> or a possessive pronoun before a noun is not a requirement in Russian, > >> as I'm sure you know. In this particular phase it would be enough to say > >> 'не поддерживается принтером'. No need to literally match English variant. > > 'your printer' and 'this printer' have two distinct and different meanings, > > please avoid inventing new traslation rules unless you have a degree in this > > area. > Could we talk about this particular case instead of making > generalizations or discussing degrees? Thing is distinction is not > important here, 'your' exists in English variant because it has to. If it's not important then there is nothing to discuss and "fix". In general it's important IMHO to keep translated text match its english version as much as possible. One of the reasons is to avoid other translators from fixing the mismatches, another is to really keep the UI consistent in different languages. -- Dmitry.

April 6, 2014

Re: po: Revise Russian translation

by Nikolay Sivov

On 4/6/2014 06:55, Dmitry Timoshkov wrote: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>>> Looks good. I especially like changes like these: >>>> >>>> --- >>>> -msgstr "Пожалуйста, выберите файл." >>>> +msgstr "Выберите файл." >>> No, this doesn't match the original english text. >> I matches okay and sounds better. Verb form is already in plural which >> makes 'please' redundant. > 'Please' is never redundant, please don't invent new rules. Or should I omit > 'please' here? No, you can't. There's no way to express it in English, don't be silly. Suggested form is shorter and has exactly same meaning - politely asks to do something. > >> Same thing as for 'Вы' garbage when used to >> address one person. > Oh, probably one should ask how well did you learn Russian in school. You sure you got what I mean? > >>> Some other translations >>> don't match either, for instance >>> >>>> "This large number of copies is not supported by your printer.\n" >>>> "Please enter a value between 1 and %d." >>>> msgstr "" >>>> -"Такое большое количество копий не может быть напечатано вашим принтером.\n" >>>> +"Такое большое количество копий не может быть напечатано этим принтером.\n" >>>> >> What you mean? 'your' translated literally is out of place here. Article >> or a possessive pronoun before a noun is not a requirement in Russian, >> as I'm sure you know. In this particular phase it would be enough to say >> 'не поддерживается принтером'. No need to literally match English variant. > 'your printer' and 'this printer' have two distinct and different meanings, > please avoid inventing new traslation rules unless you have a degree in this > area. Could we talk about this particular case instead of making generalizations or discussing degrees? Thing is distinction is not important here, 'your' exists in English variant because it has to.

April 6, 2014

Re: po: Revise Russian translation

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> Looks good. I especially like changes like these: > >> > >> --- > >> -msgstr "Пожалуйста, выберите файл." > >> +msgstr "Выберите файл." > > No, this doesn't match the original english text. > I matches okay and sounds better. Verb form is already in plural which > makes 'please' redundant. 'Please' is never redundant, please don't invent new rules. Or should I omit 'please' here? > Same thing as for 'Вы' garbage when used to > address one person. Oh, probably one should ask how well did you learn Russian in school. > > Some other translations > > don't match either, for instance > > > >> "This large number of copies is not supported by your printer.\n" > >> "Please enter a value between 1 and %d." > >> msgstr "" > >> -"Такое большое количество копий не может быть напечатано вашим принтером.\n" > >> +"Такое большое количество копий не может быть напечатано этим принтером.\n" > >> > What you mean? 'your' translated literally is out of place here. Article > or a possessive pronoun before a noun is not a requirement in Russian, > as I'm sure you know. In this particular phase it would be enough to say > 'не поддерживается принтером'. No need to literally match English variant. 'your printer' and 'this printer' have two distinct and different meanings, please avoid inventing new traslation rules unless you have a degree in this area. -- Dmitry.

April 6, 2014