Re: po: fixed remaining Slovenian true positives in the winepo error report

[Jaka Kranjc]

On Wednesday 22 of February 2012 22:25:30 Francois Gouget wrote:
> > Too bad, I missed it. The two usage strings are identical though, so why
> > not split the formalities away after the strings are thawed? Translators
> > that don't use tools with translation memory will just have more work
> > this way.
> That's what should happen eventually. In fact start's messages need a
> thorough rework because it's a pain to work with right now. Also there's
> probably improvements to be made for all command line tools with regards
> to line wrapping. But it's going to take some work and that will all
> have to wait after the 1.4 release as we are in a string freeze right
> now.
Then I suggest it be split into separate strings for each command/parameter 
line and context added to mention any wrapping limit. Maybe even just the 
parts in the second column, so you don't have to bother checking whether 
people accidentally translated the flags. This would be optimal from a 
translator's perspective, but I fear the other programmers would revolt in 
disgust. :)

LP
-- 
To err is humor

Re: TranslateWiki

[Vitaliy Margolen]

On 02/22/2012 09:09 AM, Aric Stewart wrote:

Hi,

I just had a very good conversation with the mediawiki people about
TranslateWiki. (http://translatewiki.net/wiki/Main_Page)

There are some snags right now but they are really interested in doing work
to accommodate us. We will see where that goes but so far it is looking like
the most promising path.


Maybe the whole problem is that we doing it wrong? Why do we need to track 
contribution? One of the main reasons I can thing of is LGPL constrains. 
What if we change license on .po files to something that is less stricter 
and allows easier integration with translation sites?


Just my 2c.

Vitaliy.

Re: Obscure texts and invalid translations

[Francois Gouget]

On Thu, 23 Feb 2012, Frédéric Delanoy wrote:
[...]
> > In theory message contexts are not the right tool to pass commentary
> > about the string to translate either.
> 
> I think they are (depending on your definition of commentary)
> (from 
> http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Contexts.html#Contexts)

Which is from a section about solving collisions where the same string 
is used in two contexts that should receive different translations.

> [speaking of short strings]
> "The problem is that many of the strings which have to be translated
> are very short. They have to appear in pull-down menus which restricts
> the length. But strings which are not containing entire sentences or
> at least large fragments of a sentence may appear in more than one
> situation in the program but might have different translations. This
> is especially true for the one-word strings which are frequently used
> in GUI programs."

That's just an explanation of why one tends to run into this collision 
issue.


[...]
> TBH "#." extracted comments and message contexts seem redundant, since
> both would need to be examined by the translator.

They are not redundant as they are used for different things. For 
instance:

/* This refers to the France Telecom mobile offering */
offer = dpgettext("wine", "mobile offer", "Open");

->  #. This refers to the France Telecom mobile offering
msgctxt "mobile offer"
msgid "Open"
msgstr "Open"

Putting the comment in the message context would be a serious abuse. 
Also, if you where to then replace 'France Telecom' with 'Orange' in the 
context you'd invalidate all the translations whereas if it be fine in 
the comment.

The comments can also be aggregated so you get information about exactly 
how the string is used in each instance. This can be helpful to detect 
that indeed there are conflicts.

-- 
Francois Gouget   http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.

Re: Obscure texts and invalid translations

[Frédéric Delanoy]

2012/2/22 Francois Gouget :
> On Wed, 22 Feb 2012, Frédéric Delanoy wrote:
>
>> 2012/2/22 Lauri Kenttä :
>> > Hi,
>> >
>> > Wine has many texts, especially error messages, that are almost impossible
>> > to translate without knowing what they're really about. Some are also easy
>> > to misunderstand.
>> >
>> > An example from dlls/kernel32/winerror.mc:
>> > msgid "Notify change request in progress.\n"
> [...]
>> > 1) What should I do if I wanted to clarify a msgid? Just change the 
>> > original
>> > .rc file?
>> Adding a message context. Wine translating page
>> (http://wiki.winehq.org/Translating) has some info on this. Not sure
>> if it applies to winerror messages, though
>
> Wine's winerror messages a pretty terse and usually not full sentences.
> One thing we noticed recently(*) is that the Windows ones are much
> longer and form full sentences and as a result are likely less
> ambiguous. So in the case of the winerror messages the correct fix is
> probably to simply rewrite the message so it is an unambiguous full
> sentence.

Or simply make it clearer (if needed). The fact that Windows uses
long/full sentences doesn't mean we have to mimic that per se.

>> > 2) Is there a way to add helpful comments to all language files at once
>> > without changing the msgid?
>> See above
>
> 
>
> In theory message contexts are not the right tool to pass commentary
> about the string to translate either.

I think they are (depending on your definition of commentary)
(from 
http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Contexts.html#Contexts)
[speaking of short strings]
"The problem is that many of the strings which have to be translated
are very short. They have to appear in pull-down menus which restricts
the length. But strings which are not containing entire sentences or
at least large fragments of a sentence may appear in more than one
situation in the program but might have different translations. This
is especially true for the one-word strings which are frequently used
in GUI programs."

> Normally xgettext takes the
> comments preceding the string to be translated in a PO file as lines
> starting with '#. '. But in our case RC files are processed by wrc which
> I believe does not have a means to access the comments in the RC file.

Well in that case it's simply a feature missing in wrc. But that
probably won't be "fixed"
TBH "#." extracted comments and message contexts seem redundant, since
both would need to be examined by the translator.
But the need for extracted comments (#.) usually indicates that the
msgid needs to be clarified instead.

> This is why in Wine we normally use message contexts and will likely
> have to continue doing so. For now it works fine anyway.
>
> In the future we may get into trouble if we start doing that extensively
> and the same string gets two different 'comments' as this would result
> in different contexts, hence requiring translators to translate twice.
> For instance:
>
>    "msgctxt#Shown in the File Open dialog#OK"
> and
>    "msgctxt#Shown in the Print dialog#OK"
>
>  -> "OK" needs to be translated twice when that was not the intent
>
> For now we can avoid this by limiting our 'commenting' to the cases that
> really need it.

Obviously.
What we definitely want to avoid, though, is very short
"non-propositions", like one-word adjectives for example: this
can/will cause issues in languages where adjectives agreements are
used.

Frédéric

Re: Hungarian translation patch 2

[Francois Gouget]

Thanks. That first patch made quite a big difference already. Hungarian 
is now in the 90% range :-)

I noticed some issues though:

-#, fuzzy
 msgid "&Modify/Remove"
 msgstr "&Módosítás/Eltávolítás..."

You should remove the ellipsis here.


 msgctxt "Saturation"
 msgid "&Sat:"
-msgstr ""
+msgstr "&Telítettség:"

 msgctxt "Luminance"
 msgid "&Lum:"
-msgstr ""
+msgstr "&Fényerő"

These two may be too long, hence why they are truncated in English. You 
can check in winecfg. Go to Desktop Integration, pick an Item, click on 
Color and click on Define Custom Colors. They should also have a 
trailing colon.


 msgctxt "All key"
 msgid "A"
-msgstr ""
+msgstr "A"

Given that 'All' is translated into 'Mind', this should most likely be 
an 'M'.


-#, fuzzy
 msgid "Certificate &status:"
-msgstr "Tanusítvány beszerzés"
+msgstr "Tanusítvány &állapot"

-#, fuzzy
 msgid "&Friendly name:"
 msgstr "Keresztnév"

More missing colons... Also the second one looks like it's supposed to 
have a keyboard shortcut.


 msgid "Connection is active.\n"
-msgstr "Kapcsolat aktív"
+msgstr "Kapcsolat aktív\n"

This one should probably have a trailing full stop.



You'll find more issues like this on the Wine PO site.
http://fgouget.free.fr/wine-po/


Specifically:
http://fgouget.free.fr/wine-po/hu-errors.html


-- 
Francois Gouget   http://fgouget.free.fr/
   La terre est une bêta...

Re: Alexandre Julliard : gdi32: Avoid overflows for invalid coordinates in line clipping.

[Alexandre Julliard]

Charles Davis  writes:

> On Feb 22, 2012, at 1:27 PM, Alexandre Julliard wrote:
>> --- a/dlls/gdi32/dibdrv/objects.c
>> +++ b/dlls/gdi32/dibdrv/objects.c
>> @@ -372,7 +372,8 @@ static inline DWORD calc_outcode(const POINT *pt, const 
>> RECT *clip)
>> int clip_line(const POINT *start, const POINT *end, const RECT *clip,
>>   const bres_params *params, POINT *pt1, POINT *pt2)
>> {
>> -int m, n;
>> +
>> +INT64 m, n;  /* 64-bit to avoid overflows (FIXME: find a more efficient 
>> way) */

> What about MulDiv()? As I recall, this is the sort of situation for
> which it was designed. Or is that not efficient?

It could possibly be made to work, but MulDiv's rounding is different,
and adding the bias would be more complicated.

-- 
Alexandre Julliard
julli...@winehq.org

Re: po: Spanish translation update for appwiz.rc and comdlg32.rc

[Francois Gouget]

On Wed, 22 Feb 2012, Eduardo Garcia wrote:

> This is the first patch of a series of patches aiming to update and complete
> the Spanish interface in current Wine. This patch covers appwiz.rc and
> comdlg32.rc.

Cool. Thanks!

I noticed some issues though:

msgid "Publisher:"
-msgstr "Editor:"
+msgstr "Fabricante"
 
You should not remove the colon here.

 msgctxt "Saturation"
 msgid "&Sat:"
-msgstr "&Sat.:"
+msgstr "&Saturaci??n:"

 msgctxt "Luminance"
 msgid "&Lum:"
-msgstr "&Lum.:"
+msgstr "&Luminancia:"

These two are likely to be too long, hence why it's truncated.


-#, fuzzy
 msgid "Files of type:"
-msgstr "Archivos de &tipo:"
+msgstr "&Tipo de archivo:"

Apparently that one is not meant to have a key shortcut.


-- 
Francois Gouget   http://fgouget.free.fr/
 The greatest programming project of all took six days; on the seventh day the
  programmer rested. We've been trying to debug the *&^%$#@ thing ever since.
  Moral: design before you implement.

Re: Obscure texts and invalid translations

[Francois Gouget]

On Wed, 22 Feb 2012, Frédéric Delanoy wrote:

> 2012/2/22 Lauri Kenttä :
> > Hi,
> >
> > Wine has many texts, especially error messages, that are almost impossible
> > to translate without knowing what they're really about. Some are also easy
> > to misunderstand.
> >
> > An example from dlls/kernel32/winerror.mc:
> > msgid "Notify change request in progress.\n"
[...]
> > 1) What should I do if I wanted to clarify a msgid? Just change the original
> > .rc file?
> Adding a message context. Wine translating page
> (http://wiki.winehq.org/Translating) has some info on this. Not sure
> if it applies to winerror messages, though

Wine's winerror messages a pretty terse and usually not full sentences. 
One thing we noticed recently(*) is that the Windows ones are much 
longer and form full sentences and as a result are likely less 
ambiguous. So in the case of the winerror messages the correct fix is 
probably to simply rewrite the message so it is an unambiguous full 
sentence.

(*) http://www.winehq.org/pipermail/wine-devel/2012-January/093969.html


> > 2) Is there a way to add helpful comments to all language files at once
> > without changing the msgid?
> See above



In theory message contexts are not the right tool to pass commentary 
about the string to translate either. Normally xgettext takes the 
comments preceding the string to be translated in a PO file as lines 
starting with '#. '. But in our case RC files are processed by wrc which 
I believe does not have a means to access the comments in the RC file. 
This is why in Wine we normally use message contexts and will likely 
have to continue doing so. For now it works fine anyway.

In the future we may get into trouble if we start doing that extensively 
and the same string gets two different 'comments' as this would result 
in different contexts, hence requiring translators to translate twice. 
For instance:

"msgctxt#Shown in the File Open dialog#OK"
and
"msgctxt#Shown in the Print dialog#OK"

 -> "OK" needs to be translated twice when that was not the intent

For now we can avoid this by limiting our 'commenting' to the cases that 
really need it.




> > 4) There has been discussions about some translation websites. Is there a
> > chance that such a website would allow easy tagging of potential errors?
> 
> Problem is attribution of changes to respective authors (+ potential
> license conflicts). Search the wine-devel archives for more info.

Good starting points:
http://wiki.winehq.org/Translating#head-e1a500fef50a1801ecea706ebd9b51457943f102
and
http://www.winehq.org/pipermail/wine-devel/2012-February/094302.html

-- 
Francois Gouget   http://fgouget.free.fr/
 Avoid the Gates of Hell - use Linux.

Re: Alexandre Julliard : gdi32: Avoid overflows for invalid coordinates in line clipping.

[Charles Davis]

On Feb 22, 2012, at 1:27 PM, Alexandre Julliard wrote:
> --- a/dlls/gdi32/dibdrv/objects.c
> +++ b/dlls/gdi32/dibdrv/objects.c
> @@ -372,7 +372,8 @@ static inline DWORD calc_outcode(const POINT *pt, const 
> RECT *clip)
> int clip_line(const POINT *start, const POINT *end, const RECT *clip,
>   const bres_params *params, POINT *pt1, POINT *pt2)
> {
> -int m, n;
> +
> +INT64 m, n;  /* 64-bit to avoid overflows (FIXME: find a more efficient 
> way) */
What about MulDiv()? As I recall, this is the sort of situation for which it 
was designed. Or is that not efficient?

Chip

Re: po: fixed remaining Slovenian true positives in the winepo error report

[Francois Gouget]

On Wed, 22 Feb 2012, Jaka Kranjc wrote:
[...]
> > Also in my previous email I forgot to mention that the /Unix line is
> > missing from both start.exe usage strings, not just the one I mentionned
> > before. Hopefully you will have noticed that already.
> Too bad, I missed it. The two usage strings are identical though, so why not 
> split the formalities away after the strings are thawed? Translators that 
> don't use tools with translation memory will just have more work this way.

That's what should happen eventually. In fact start's messages need a 
thorough rework because it's a pain to work with right now. Also there's 
probably improvements to be made for all command line tools with regards 
to line wrapping. But it's going to take some work and that will all 
have to wait after the 1.4 release as we are in a string freeze right 
now.

-- 
Francois Gouget   http://fgouget.free.fr/
   If it stinks, it's chemistry. If it moves, it's biology.
  If it does not work, it's computer science.

Re: Obscure texts and invalid translations

[Frédéric Delanoy]

2012/2/22 Lauri Kenttä :
> Hi,
>
> Wine has many texts, especially error messages, that are almost impossible
> to translate without knowing what they're really about. Some are also easy
> to misunderstand.
>
> An example from dlls/kernel32/winerror.mc:
> msgid "Notify change request in progress.\n"
>
> Some interpretations:
> de, nb: "A request for notifications about changes is in progress."
> fr, sv: "A request to change a notification is in progress."
> it, pt: Both have their own versions, I think.
>
> There are many more such cases, although the difference is usually in only
> one or two languages. (Unfortunately it didn't occur to me to put them down
> from the beginning, so I can't give you a list. I'll just mention "Challenge
> Password" before I forget that, too.)
>
> 1) What should I do if I wanted to clarify a msgid? Just change the original
> .rc file?
Adding a message context. Wine translating page
(http://wiki.winehq.org/Translating) has some info on this. Not sure
if it applies to winerror messages, though

> 2) Is there a way to add helpful comments to all language files at once
> without changing the msgid?
See above

> 3) What should I do if I spot a suspicious translation? Spam the Bugzilla,
> contact the Last-Translator personally

Last-Translator is not reliable. It might be updated by some
tools/manually, but it's not guaranteed.
You can use git-blame to find the last author of a specific line
Spamming bugzilla is not an option IMO.

> , or send patches to add #fuzzy comments and hope I'm right?
If you only *hope* to be right, don't send such patches

> And if it's wrong in many of the languages I
> can read, it's probably wrong in some others as well; who would check them
> all?
Their respective translators. Sadly many translations are not that
well maintained.

> 4) There has been discussions about some translation websites. Is there a
> chance that such a website would allow easy tagging of potential errors?

Problem is attribution of changes to respective authors (+ potential
license conflicts). Search the wine-devel archives for more info.
> --
> Lauri Kenttä

Frédéric

Obscure texts and invalid translations

[Lauri Kenttä]

Hi,

Wine has many texts, especially error messages, that are almost 
impossible to translate without knowing what they're really about. Some 
are also easy to misunderstand.


An example from dlls/kernel32/winerror.mc:
msgid "Notify change request in progress.\n"

Some interpretations:
de, nb: "A request for notifications about changes is in progress."
fr, sv: "A request to change a notification is in progress."
it, pt: Both have their own versions, I think.

There are many more such cases, although the difference is usually in 
only one or two languages. (Unfortunately it didn't occur to me to put 
them down from the beginning, so I can't give you a list. I'll just 
mention "Challenge Password" before I forget that, too.)


1) What should I do if I wanted to clarify a msgid? Just change the 
original .rc file?


2) Is there a way to add helpful comments to all language files at once 
without changing the msgid?


3) What should I do if I spot a suspicious translation? Spam the 
Bugzilla, contact the Last-Translator personally, or send patches to add 
#fuzzy comments and hope I'm right? And if it's wrong in many of the 
languages I can read, it's probably wrong in some others as well; who 
would check them all?


4) There has been discussions about some translation websites. Is there 
a chance that such a website would allow easy tagging of potential 
errors?


--
Lauri Kenttä

Re: winealsa.drv patch to enum all software devices from .asoundrc

[Chris Robinson]

On Wednesday, February 22, 2012 11:42:13 AM joerg-cyril.hoe...@t-systems.com 
wrote:
> That's why I'll repeat once more and say that DSound's resampler should
> become that one.
> 
> My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY
> etc.) tells me it's compatible with such a scheme: there are restriction on
> when you're allowed to invoke SetFormat on the Primary buffer.

DSound needs to resample itself anyway, to mix all the secondary buffers to 
the output stream. If winmm streams are implemented using secondary buffers on 
dsound, then there's no issue with making resampling as dsound will do it.

I'd also wager that DSound's primary buffer is largely faked. It's telling 
that the primary buffer is (in tests Maarten and I have done) always 32768 
bytes, even for output modes where that isn't a multiple, or where it can only 
hold 20ms of audio.

I would say IDirectSoundBuffer::SetFormat accepts reasonable any rate, 
although it outputs using the mmdevapi device rate, and WRITE_PRIMARY emulates 
primary access by using a secondary buffer, which can be set to the specified 
rate.

Re: po: fixed remaining Slovenian true positives in the winepo error report

[Jaka Kranjc]

On Wednesday 22 of February 2012 18:16:20 Francois Gouget wrote:
> On Wed, 22 Feb 2012, Jaka Kranjc wrote:
> [...]
> 
> > > You mean that all the 'not translated' strings are actually translated
> > > and just happen to be the same as in English, right? I can add them.
> > 
> > Exactly.
> 
> Done.
Great.

I also swapped wine-patches with wine-devel to keep the noise down.

> So in English you'd end up with something like this:
> 
>Error; Paper jam;
> or
>Initialising; Default Printer; I/O Active;
> 
> 
> So what you're saying is that:
>  * There is no systematic conversion of semicolons to commas in
>Slovenian.
>  * In Slovenian the strings above should definitely use a comma
>because it's used as a list separator.
>  * The English string should maybe use a comma too? This may require
>some supporting arguments...
So if I understand correctly, parts of this composite get choped and 
concatenated and then printed as a sequence. Lacking full sentences, 
semicolons *are* a good choice for Slovenian in this case too. Commas would be 
fitting for proper "etc" lists.

This brings up another can of worms though; capitalisation. We don't use title 
case at all, so these translation have the wrong case. Well, except for the 
first one being printed, but that is runtime knowledge, so we can't really fix 
it well. Gettext has no provisions for this (or gender or ...), so all that 
comes to mind is autocapitalisation depending on the locale, but that is 
probably ugly and I doubt it would work with more exotic scripts (but not sure 
if any would need it).

> > So no, in general we do not substitute semicolons, but it depends on the
> > original msgid context. Most translators are serious grammar nazis, so
> > they/we tend to ignore mistakes in the original string.
> 
> Don't!
> 
> At least for Wine any issue in the English string should be fixed or
> reported so it can be fixed as early as possible (preferably before it
> has been translated into 20 other languages). Of course I'm saying that
> but being in string freeze we would not be able to fix strings right
> now. But if I saw such reports on wine-devel I'd make sure they are
> acted upon after the release.
Oh, I know, didn't mean to suggest inaction. But in a lot of cases, it comes 
down to preference, style or language perception. Plus the fact that 
inspecting the original's validity almost always requires the ability to read 
code, which most translators lack and which is hard to access if they work via 
online translation tools.

Re usage strings: is there no 80 column limit imposed? I saw even some 
original strings were longer.

LP
-- 
To err is humor

TranslateWiki

[Aric Stewart]

Hi,

I just had a very good conversation with the mediawiki people about 
TranslateWiki. (http://translatewiki.net/wiki/Main_Page)


There are some snags right now but they are really interested in doing 
work to accommodate us. We will see where that goes but so far it is 
looking like the most promising path.


-aric

Re: Translators wanted!

[Aric Stewart]

On 2/22/12 8:08 AM, Yaron Shahrabani wrote:

Hey Aric, can you please explain?
In both Pootle and Transifex you can have a language maintainer.

In Pootle you can set permissions for each and every user as the
maintainer while in Transifex you can only allow or disallow people who
want to assist (And they have full permissions, they can affect the
translation without the intervention of the maintainer).

Or am I getting it all wrong?

Kind regards,
YaronShahrabani




I admit I have mostly experience with pootle 2.1.6 and not the tip, but 
I have subscribe to the pootle-dev mailing list to see if i can get some 
more insight.


The problem comes with if you have 2+ translators for a language.

Translator 'A' is the admin,  'B' and 'C' can just suggest.

if 'B' suggests some translations and 'C' suggests some others.  'A' 
does have to approve them all  however we have no way to go back and 
generate a report after the fact as to which translations came from 'B' 
or 'C'  or even which 'A' submitted directly.


I am not familiar with Transifex. I will have to look at that.

-aric

Re: Translators wanted!

[Yaron Shahrabani]

Hey Aric, can you please explain?
In both Pootle and Transifex you can have a language maintainer.

In Pootle you can set permissions for each and every user as the maintainer
while in Transifex you can only allow or disallow people who want to assist
(And they have full permissions, they can affect the translation without
the intervention of the maintainer).

Or am I getting it all wrong?

Kind regards,
Yaron Shahrabani






On Wed, Feb 22, 2012 at 3:45 PM, Aric Stewart  wrote:

> We would love to do this and it is being explored.
>
> The core issue is the ability to directly connect each translation to the
> translator. None of the platforms we have looked at have this functionality.
>
> If i have more time I can try to explore the pootle code as I  have at
> least passing familiarity with it... But out of the box it does not do what
> we need.
>
> -aric
>
>
> On 2/22/12 6:10 AM, Yaron Shahrabani wrote:
>
>> Can we please discuss about moving the translation to another platform?
>>
>> Pootle seems the most appropriate so far, do you guys need more details?
>>
>> Kind regards,
>> YaronShahrabani
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 17, 2012 at 11:35 PM, Yaron Shahrabani > > wrote:
>>
>>Transifex allows that although Pootle has a much more sophisticated
>>permissions mechanism allowing people to only suggest while other
>>can actually edit the translation.
>>
>>Transifex has a binary permissions mechanism, a person can either
>>edit or not edit but he cannot suggest.
>>
>>So yes, that's possible, what else do we need?
>>
>>
>>Kind regards,
>>YaronShahrabani
>>
>>
>>
>>
>>
>>
>>On Fri, Feb 17, 2012  at 1:27 PM, Alex Bradbury
>>mailto:a...@asbradbury.org>> wrote:
>>
>>On 17 February 2012  11:12, Yaron Shahrabani
>>
>>mailto:sh.ya...@gmail.com>> wrote:
>> > I would go for the more popular options such as Transifex,
>>TranslateWiki, or
>> > Pootle.
>> >
>> > Is this even an option?
>>
>>See
>>http://wiki.winehq.org/**Translating#head-**
>> e1a500fef50a1801ecea706ebd9b51**457943f102
>>"3. Web-based translations systems"
>>
>>Quoting below for convenience:
>>
>>---
>>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.
>>---
>>
>>
>>
>>
>>
>>
>>
>
>

Re: Translators wanted!

[Aric Stewart]

We would love to do this and it is being explored.

The core issue is the ability to directly connect each translation to 
the translator. None of the platforms we have looked at have this 
functionality.


If i have more time I can try to explore the pootle code as I  have at 
least passing familiarity with it... But out of the box it does not do 
what we need.


-aric

On 2/22/12 6:10 AM, Yaron Shahrabani wrote:

Can we please discuss about moving the translation to another platform?

Pootle seems the most appropriate so far, do you guys need more details?

Kind regards,
YaronShahrabani






On Fri, Feb 17, 2012 at 11:35 PM, Yaron Shahrabani mailto:sh.ya...@gmail.com>> wrote:

Transifex allows that although Pootle has a much more sophisticated
permissions mechanism allowing people to only suggest while other
can actually edit the translation.

Transifex has a binary permissions mechanism, a person can either
edit or not edit but he cannot suggest.

So yes, that's possible, what else do we need?


Kind regards,
YaronShahrabani






On Fri, Feb 17, 2012  at 1:27 PM, Alex Bradbury
mailto:a...@asbradbury.org>> wrote:

On 17 February 2012  11:12, Yaron Shahrabani
mailto:sh.ya...@gmail.com>> wrote:
 > I would go for the more popular options such as Transifex,
TranslateWiki, or
 > Pootle.
 >
 > Is this even an option?

See

http://wiki.winehq.org/Translating#head-e1a500fef50a1801ecea706ebd9b51457943f102
"3. Web-based translations systems"

Quoting below for convenience:

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

Re: Translators wanted!

[Yaron Shahrabani]

Can we please discuss about moving the translation to another platform?

Pootle seems the most appropriate so far, do you guys need more details?

Kind regards,
Yaron Shahrabani






On Fri, Feb 17, 2012 at 11:35 PM, Yaron Shahrabani wrote:

> Transifex allows that although Pootle has a much more sophisticated
> permissions mechanism allowing people to only suggest while other can
> actually edit the translation.
>
> Transifex has a binary permissions mechanism, a person can either edit or
> not edit but he cannot suggest.
>
> So yes, that's possible, what else do we need?
>
>
> Kind regards,
> Yaron Shahrabani
>
> 
>
>
>
>
> On Fri, Feb 17, 2012 at 1:27 PM, Alex Bradbury  wrote:
>
>> On 17 February 2012 11:12, Yaron Shahrabani  wrote:
>> > I would go for the more popular options such as Transifex,
>> TranslateWiki, or
>> > Pootle.
>> >
>> > Is this even an option?
>>
>> See
>> http://wiki.winehq.org/Translating#head-e1a500fef50a1801ecea706ebd9b51457943f102
>> "3. Web-based translations systems"
>>
>> Quoting below for convenience:
>>
>> ---
>> 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.
>> ---
>>
>
>

Re: winealsa.drv patch to enum all software devices from .asoundrc

[Joerg-Cyril . Hoehle]

Hi,

Chris Robinson wrote:
>> You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
>Interestingly, this flag seems to only have an effect for already-initialized 
>streams. ALSA would need a way to adjust the rate of an opened device for this 
>to work.

My view on it is this: given that it's said to work in shared mode only, I 
believe
it gives limited access to MS' internal resampler device.  Output is still 
driven at
the mixer's nomimal rate, there's no need to adjust the rate of an open ALSA 
back-end.

IOW, if you were to implement winmm on top of mmdevapi in w7, here's what you'd 
do:
. Call Activate
. Call GetMixFormat
. If rate is different from requested, add AUDCLNT_STREAMFLAGS_RATEADJUST
. call Initialize
. If rate is different, call SetSampleRate

The native resampler adjusts the rates, the mixer adjusts bit width and 
whatever entity adjusts
the channel mapping (formerly the NT kernel mixer was said to do that).

I suppose MS' mmdevapi behaves like gstreamer as a sequence of audio filters and
converters. If you ask for a rate resampler, it'll plug one into the chain.  
Plugging can
only be performed at initialization time, there's no further dynamic 
reconfiguration.

That's why I'll repeat once more and say that DSound's resampler should become 
that one.

My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY etc.)
tells me it's compatible with such a scheme: there are restriction on when 
you're allowed to
invoke SetFormat on the Primary buffer.

Regards,
 Jörg Höhle

Re: [PATCH] README: updated Linux and FreeBSD kernels

[Francois Gouget]

On Wed, 22 Feb 2012, Marcus Meissner wrote:

> ---
>  README |   13 ++---
>  1 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/README b/README
> index baa6ab3..0cbb047 100644
> --- a/README
> +++ b/README
> @@ -29,7 +29,7 @@ especially the wealth of information found at 
> http://www.winehq.org.
>  To compile and run Wine, you must have one of the following:
>  
>Linux version 2.0.36 or above
> -  FreeBSD 6.3 or later
> +  FreeBSD 8.0 or later
[...]
>  FreeBSD info:
> -  Wine will generally not work properly on versions before FreeBSD
> -  6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See
> -  http://wiki.freebsd.org/Wine for more information.
> +  Wine will generally not work properly on versions before FreeBSD 8.0.
> +  See http://wiki.freebsd.org/Wine for more information.

Is there a reason why Wine won't work right on FreeBSD 7.0?
Winetest seems mostly ok.
http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_BSD.html


-- 
Francois Gouget   http://fgouget.free.fr/
It really galls me that most of the computer power in the world
  is wasted on screen savers.
 Chris Caldwell from the GIMPS project
   http://www.mersenne.org/prime.htm