Re: [docs] winelib: Use proper entity escaping for '&','<' and '>'
Hi Frédéric, > - $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $< | $(WRC) -N $(WRCFLAGS) > $(WINELIB_FLAGS) -o $@ > + $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $lt; | $(WRC) -N $(WRCFLAGS) > $(WINELIB_FLAGS) -o $@ looks like you forgot the "&". Best, Julian
Re: Manpage patch, please review
> >> i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI > > > > So, do you think I should leave it? To the average reader, CLI should be > > clearer. I thought it was a typo at first. ;) > > I'd leave it. Anyone else? Ironically, in the existing German translation it says CLI. > >>> Should paths be bold or italic/underlined? > >> > >> Not sure, are there other guidelines out there we can use? > > > > Anyone else? > > Did Frédérics recent patches handle that? I can't really tell, although there are a few occurrences that look similar, like -outputs the data either in a standard \fB.bin\fR formatted binary +outputs the data either in a standard \fI.bin\fR formatted binary If nobody else speaks up, I'll give it a shot, maybe leave out the CUI/CLI part for now. Thanks, André!
Re: Manpage patch, please review
> Frédéric has done it quite good, because it's committed :) > Further you can't compile Wine in 64-bit mode on 32-bit that easily, and you > can't run it, your version doesn't handle that. Naturally. But yeah, I guess not everyone knows that, good point. > > CUI -> CLI: > > According to Google and Wikipedia, CLI is more common. > > i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI So, do you think I should leave it? To the average reader, CLI should be clearer. I thought it was a typo at first. ;) > > Should paths be bold or italic/underlined? > > Not sure, are there other guidelines out there we can use? Anyone else? Best, Julian
Manpage patch, please review
Hi all! While working on the translation of the (main) manpage, I noticed a few issues in the English version and started working on a patch. That was quite some time ago, I had little spare time lately and didn't get around to finish and send it in. So I figured I just take what I have now and ask you guys for comments. I appreciate any remarks or suggestions. Thanks, Julian Notes: I had a change similar to Frédéric's, mentioning wine can run 64-bit programs now. He was quicker and I like his wording better. I had something like "[...]or Win64 executable (if your version of wine was compiled with 64-bit support)." I guess that would be more confusing to people using their distro's wine packages and people compiling their own wine know that anyway. Do you agree or do you think it's better to be more specific? CUI -> CLI: According to Google and Wikipedia, CLI is more common. -.BR @bindir@/wineserver , +.IR @bindir@/wineserver , and following, similar changes: This is the way it is formatted in the wineserver manpage. I noticed there is no uniform style across our manpages, so we should have a guideline. Should paths be bold or italic/underlined? >From 66391fbb22bdb150333b99e05250df4a3fa6f3f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Julian=20R=C3=BCger?= Date: Tue, 16 Jul 2013 19:29:34 +0200 Subject: loader: Various small manpage improvements. --- loader/wine.man.in | 56 1 file changed, 26 insertions(+), 30 deletions(-) diff --git a/loader/wine.man.in b/loader/wine.man.in index aac5e75..84db685 100644 --- a/loader/wine.man.in +++ b/loader/wine.man.in @@ -1,4 +1,5 @@ -.TH WINE 1 "July 2013" "@PACKAGE_STRING@" "Windows On Unix" +.\" -*- nroff -*- +.TH WINE 1 "October 2005" "@PACKAGE_STRING@" "Windows On Unix" .SH NAME wine \- run Windows programs on Unix .SH SYNOPSIS @@ -10,8 +11,7 @@ wine \- run Windows programs on Unix .B wine --version .PP For instructions on passing arguments to Windows programs, please see the -.B -PROGRAM/ARGUMENTS +.B PROGRAM/ARGUMENTS section of the man page. .SH DESCRIPTION .B wine @@ -22,14 +22,14 @@ For debugging wine, use .B winedbg instead. .PP -For running CUI executables (Windows console programs), use +For running CLI executables (Windows console programs), use .B wineconsole instead of .BR wine . -This will display all the output in a separate windows (this requires X11 to -run). Not using +This will display the program's output in a separate window (requires a +graphical environment using the X11 or Mac driver to run). Not using .B wineconsole -for CUI programs will only provide very limited console support, and your +for CLI programs will provide very limited console support, and your program might not function properly. .PP When invoked with @@ -44,8 +44,8 @@ The program name may be specified in DOS format .RI ( C:\(rs\(rsWINDOWS\(rs\(rsSOL.EXE ) or in Unix format .RI ( /msdos/windows/sol.exe ). -You may pass arguments to the program being executed by adding them to the -end of the command line invoking +You may pass arguments to the program being executed by appending them to the +command line invoking .B wine (such as: wine notepad C:\(rs\(rsTEMP\(rs\(rsREADME.TXT). Note that you need to '\(rs' escape special characters (and spaces) when invoking Wine via @@ -55,48 +55,44 @@ wine C:\(rs\(rsProgram\(rs Files\(rs\(rsMyPrg\(rs\(rstest.exe .PP .SH ENVIRONMENT VARIABLES .B wine -makes the environment variables of the shell from which -.B wine -is started accessible to the windows/dos processes started. So use the -appropriate syntax for your shell to enter environment variables you need. -.TP +makes the environment variables of the shell from which it is run accessible +to the windows/dos processes started. Use the appropriate syntax for your +shell to enter environment variables you need. +.TP .I WINEPREFIX If set, the content of this variable is taken as the name of the directory where .B wine -stores its data (the default is +stores it's data (the default is .IR $HOME/.wine ). -This directory is also used to identify the socket which is used to -communicate with the +This directory is also used to determine the socket used for communication with the .IR wineserver . All .B wine processes using the same .B wineserver (i.e.: same user) share certain things like registry, shared memory, -and config file. +and kernel objects. By setting .I WINEPREFIX to different values for different .B wine -processes, it is possible to run a number of truly independent -.B wine -processes. +processes, it is possible to run a number of truly independent sessions. .TP .I WINESERVER Specifies the path and name of the .B wineserver binary. If not set, Wine will try to load -.BR @bindir@/wineserver , +.IR @bindir@/wineserver , and if this doesn't exist it will then look for a file named -"wineserver" in the path and in a few other likely locations. +\fIwineserver\fR in the
Re: readme: Update German translation
Am Dienstag, den 09.07.2013, 00:46 +0200 schrieb André Hentschel: > --- > documentation/README.de | 14 -- > 1 file changed, 4 insertions(+), 10 deletions(-) > Hi André and list, patch looks good to me. One minor remark: > +wine notepad.exe lesmich.txt (Programmaufruf mit Parametern) I think "liesmich" is more common than "lesmich", although both sound awkward. Do we need/want to translate that? Best, Julian PS: I have some more manpage-patches in the works, but my spare time has been a little scarce lately. Do you think 1.6 will be released Friday?
Re: server: Update German translation of manpage.
Am Dienstag, den 25.06.2013, 19:41 +0200 schrieb Alexandre Julliard: > Julian Rüger writes: > > > I'm unsure about the second line. Is that supposed to be the "last > > modified" date of the manpage, the wineserver or what? The English > > version says October 2005. > > In general, it would be the last time there were changes to the program > that required a manpage update. Thanks for the answer. So I'll change it to October 2005. Best, Julian
Re: po: Fix typos in German translation
Hi André, > -msgstr "Datagramme gesendet" > +msgstr "Datenpakete gesendet" In all my university classes, (UDP) Datagrams were translated or referred to as "Datagramme" and more or less strictly distinguished from packets. "Vollzugriff" vs. "voller Zugriff" is a matter of taste, I picked the first because back when I used Windows, that was a common term to read, but that could have just been my firewall or something. I would have preferred for it to be added to Francois' wordlist, but whatever. Best, Julian
Re: cmd: Remove a pointless linefeed in an error message.
Sorry for nagging ;) Wasn't the convention to assume an 80-character wide terminal? This line would wrap, then. So the linefeed is not totally pointless here. Please correct me, if I'm mistaken. Best regards, Julian Am Mittwoch, den 03.04.2013, 16:07 +0200 schrieb Francois Gouget: > --- > programs/cmd/cmd.rc |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/cmd/cmd.rc b/programs/cmd/cmd.rc > index c3cdb52..d464cab 100644 > --- a/programs/cmd/cmd.rc > +++ b/programs/cmd/cmd.rc > @@ -360,5 +360,5 @@ Enter HELP for further information on any of > the above commands.\n" >WCMD_NOOPERAND, "Expected an operand.\n" >WCMD_NOOPERATOR, "Expected an operator.\n" >WCMD_BADPAREN, "Mismatch in parentheses.\n" > - WCMD_BADHEXOCT, "Badly formed number - must be one of decimal (12),\n > hexadecimal (0x34) or octal (056).\n" > + WCMD_BADHEXOCT, "Badly formed number - must be one of decimal (12), > hexadecimal (0x34) or octal (056).\n" > }
Re: Re: netstat: Initial implementation (try 2)
Am Freitag, den 04.01.2013, 00:58 +0100 schrieb Frédéric Delanoy: > It seems to be a specificity in the German version: it's not translated > in the French version (tested on different windows versions). > And apparently neither in other languages, if one can > trust the various http://en.wikipedia.org/wiki/Netstat page > translations, and the various "localized" screenshots of netstat using > your favorite web search engine. > > Also, IMHO, it makes little to no sense to translate stuff like > "CLOSE_WAIT" or "FIN_WAIT1" with are part of a standard > specification... so 'hardcoding" them would not cause much harm, if at all. > > Frédéric FWIW, I also think translating these strings can only make clarity/comprehensibility worse. Even in the (highly unlikely, IMHO) case that the user does not speak English at all, the states would match those found in technical literature. At least, I have never seen them translated in German literature. I already sent a patch with translations, although I'm not particularly happy with them. It seems impossible to come up with something that does not change the meaning or sound completely awkward. German Windows 7's netstat only confirms that. Best regards, Julian
Re: Call for papers - FOSDEM 2013
It would be really cool if someone could manage to record some talks and upload them to eg. youtube, for those who can't attend. I would be especially interested in Stefan's proposed talk. Thanks everyone and have a nice FOSDEM! Best regards, Julian Am Freitag, den 02.11.2012, 14:26 +0100 schrieb Stefan Dösinger: > Am 2012-11-01 19:59, schrieb Jeremy White: > > So I would like to formally 'call for papers' for FOSDEM. Please > > email suggested topics to winec...@winehq.org, where I'll collate > > them and piece them into a schedule. > Will this be talk-only or do you also plan written conference > proceedings? I suspect it'll be talk-only. > > I propose a talk about the status of 3D rendering support for games on > Linux. I don't intend to make this highly Wine-specific, and instead > include the state of Mesa, fglrx, nvidia and OSX graphics drivers. >
Re: [1/4] Assorted spelling fixes.
Hi Francois, > - * size [I] How much percent of cache space should be free. > + * size [I] How many percents of the cache should be free. Maybe something like "Precentage of cache that should be free" would sound more natural. However I'm not sure of the intended meaning here, it could be "freed". Best regards, Julian
Re: Assorted spelling fixes.
Hi Francois, > -/* if we set the bufferpointer to NULL here UrlUnescape fails and > string gets not converted */ > +/* if we set the buffer pointer to NULL here UrlUnescape fails and > the string is not converted */ for consistency with the other buffer pointer comments and better readability, I suggest you add a comma here: +/* if we set the buffer pointer to NULL here, UrlUnescape fails and the string is not converted */ Best regards, Julian
Re: po: Update German translation
I'm very sorry for sending another private mail to the list... When I chose "Answer to sender" my Mailclient asked if I wanted to send a private mail, but the sender is wine-devel. Damn. Am Sonntag, den 26.08.2012, 17:47 +0200 schrieb Julian Rüger: > Hi André, > > war ich zu langsam? ;) > > Das Komma ist an der Stelle grammatikalisch falsch, glaube ich. > "Die verbundenen Controller" sollten auch Plural bleiben. Mein Vorschlag > wäre irgendwie so etwas: > > "Nach dem De-/Aktivieren eines Gerätes wird die Liste der verbundenen > Controller bis zum Neustart dieses Applets nicht [mehr] aktualisiert." > > Viele Grüsse, > Julian > > Am Samstag, den 25.08.2012, 13:40 +0200 schrieb André Hentschel: > > > "After disabling or enabling a device, the connected joysticks won't be " > > "updated here until you restart this applet." > >-msgstr "" > >+msgstr "Nach dem deaktivieren oder aktivieren eines Gerätes, wird der " > >+"verbundene Controller hier bis zum Neustart des Applets nicht mehr " > >+"aktualisiert."
Re: po: Update German translation
Hi André, war ich zu langsam? ;) Das Komma ist an der Stelle grammatikalisch falsch, glaube ich. "Die verbundenen Controller" sollten auch Plural bleiben. Mein Vorschlag wäre irgendwie so etwas: "Nach dem De-/Aktivieren eines Gerätes wird die Liste der verbundenen Controller bis zum Neustart dieses Applets nicht [mehr] aktualisiert." Viele Grüsse, Julian Am Samstag, den 25.08.2012, 13:40 +0200 schrieb André Hentschel: > "After disabling or enabling a device, the connected joysticks won't be " > "updated here until you restart this applet." >-msgstr "" >+msgstr "Nach dem deaktivieren oder aktivieren eines Gerätes, wird der " >+"verbundene Controller hier bis zum Neustart des Applets nicht mehr " >+"aktualisiert."
Re: change wording of ok()-messages in winspool-tests?
Francois Gouget wrote: > > > > Do you think it's worth changing these? > > Not necessarily. The only thing I'd feel like changing would be to [...] Alexandre Julliard wrote: > Test failure messages are not supposed to be seen, if they are seen it's > a bug. So it's not worth spending effort making them look nice or > consistent. OK, I won't bother then ;) Thanks a lot for your comments!
change wording of ok()-messages in winspool-tests?
Hi Francois and list, [/nitpick-mode on] I'm preparing a patch to fix typos/spelling/grammar in dlls/winspool.drv/tests/info.c, where I stumbled across repeated messages like ok( !retval, "function result wrong! False expected\n"); or ok( size == exact, "Parameter size wrong! %d expected got %d\n", exact, size); Do you think it's worth changing these? (I think "Wrong function result: 'false' expected\n", and "Wrong parameter size: expected %d, got %d\n" would be better) Do we have guidelines for strings like these? For example: start with a captial letter, no punctuation at the end... What tests have "good" style I can use as reference? Best regards, Julian PS: Am I bike shedding here? Does anyone care about stuff like this? Sorry for wasting your time ;)
Re: ru.po: improved an Russian translation
Am Dienstag, den 29.05.2012, 23:04 +0400 schrieb Oleg Yarigin: > There are some improvements of a style (now it is more official) and > non-translated empty lines. > > > To avoid an character encoding interruption, I send the diff file as a > packed text file attachment (ru_diff.txt.bz2, 22.3 KB). Hi Oleg, a few remarks about your patch: 1. Patches should be sent to wine-patc...@winehq.org, not wine-devel. However, if you only want to ask for review and not send the patch in yet, wine-devel is fine. 2. You should generate your patch using "git format-patch", see http://wiki.winehq.org/GitWine 3. You have a lot of changes like this: > #: crypt32.rc:198 > msgid "Access Method=" > -msgstr "Метод доступа=" > +msgstr "Метод доступа: " I don't think that's a good idea... Afaik, the general guideline is to not change formatting and punctuation (from the English original), unless there's a rule in the Russian language that specifically dictates it. (For example in French, you need spaces in front of colons and stuff) I don't know Russian, so I may be wrong here. 4. A normal, UTF-8 formatted textfile as an attachment (preferably generated by git format-patch, see above) should suffice, you shouldn't need to pack it. I guess an archive could also confuse the automated scripts, requiring Alexandre to manually unpack it and add your patch to the incoming queue (http://source.winehq.org/patches/)... Again, I may be wrong about that, but it would not hurt I think. OK, enough of my nagging ;) Please understand this as constructive criticism, it will help getting your patch accepted and not cause extra work for the maintainer (Alexandre). It looks like you invested a lot of effort, thanks for that. I don't speak Russian, so I can't say anything else, maybe it would also help to ask the current translator for review (I think Nikolay Sivov). Best regards, Julian
Re: [Programs] Notepad: sync with ReactOS notepad (2)
Hi Carlo, thank you for working on this. I think you will improve the chances for your patches to be accepted if you give them individually meaningful names, like "notepad: Don't use reserved MSVC keyword." for patch #2. Also, like Jerome said, we may have a problem if different people commited these changes to ReactOS. I'm no expert on this, but as I understand, Wine needs the patch to be credited to the author who actually wrote the code. (Can someone else please comment on this, if I am mistaken?) Best regards, Julian
Re: msi: Tweak msiexec's usage message.
Hi Francois and wine-devel,
while we're at it, shouldn't these
>"Advertise a product:\n"
>"\t/j[u|m] package [/t transform] [/g languageid]\n"
>"Apply a patch:\n"
>"\t/p patch_package [property]\n"
>"\t/p patch_package /a package [property]\n"
also be put in curly brackets?
Like this:
\t/j[u|m] {package} [/t transform] ...
\t/p {patch_package} [property]\n
...
Best,
Julian
Re: po: Update German translation
Hi André, Am Mittwoch, den 28.03.2012, 20:37 +0200 schrieb André Hentschel: > Thx missed that, next time it's all up to you. Giving the translation stuff > completely in your hands now. :) OK, umm, thanks I guess ;) I might still bug you for approval though. Best, Julian PS: That mail was supposed to be private, since I used German, but it was late and I screwed up :)
Re: po: Update German translation
Hi André, Am Dienstag, den 27.03.2012, 21:43 +0200 schrieb André Hentschel: > --- > po/de.po |7 +++ > 1 files changed, 3 insertions(+), 4 deletions(-) > > #: jscript.rc:37 >-#, fuzzy > #| msgid "Invalid parameter.\n" > msgid "Invalid character" >-msgstr "Ungültiger Parameter.\n" >+msgstr "Ungültiges Zeichen" du solltest die alte msgid auch entfernen. (Ist ein neues Feature, wurden schon andere drauf hingewiesen ;) Viele Grüsse, Julian
Re: Spelling errors in en_US translation
Am Freitag, den 16.03.2012, 11:05 +0100 schrieb Francois Gouget: > I have not looked at the British vs. American English issues. Part of > the reason is that I'm a bit fuzzy on how we use the PO files for these. > Is the following correct? > > * All of Wine resources are supposed to be 100% American English. > * en_US is automatically filled using Wine's resources. > * en is manually translated to British English, essentially like any >other language. This should be answered by someone more qualified, but it makes sense to me ;) > Why en rather than en_GB? > Should en.po only contain translations where British differs from > American English? But then how do we know that the translation is > complete? Maybe we should rename en.po? > There is also a bug that claims having en.po be incomplete causes > trouble, though I could not observe that and am pretty skeptical: > > http://bugs.winehq.org/show_bug.cgi?id=29924 Yep, I'm on the CC list for that, but could not reproduce until now. I had an idea that I just checked, and bingo: LC_MESSAGES=en_GB.UTF-8 LC_CTYPE=fr_FR.UTF-8 ./wine control seems to work fine (everything in English), but if I replace fr_FR with my system's locale eg: LC_MESSAGES=en_GB.UTF-8 LC_CTYPE=de_DE.UTF-8 ./wine control I get a mixed English/German GUI. Will add a comment to the bug. Best regards, Julian
Re: [PATCH] po: Remove bad characters (C2 & A0) from french translations.
Am Dienstag, den 13.03.2012, 14:51 +0100 schrieb Frédéric Delanoy: > On Tue, Mar 13, 2012 at 11:52, Christian Costa wrote: > > This string exists in native devenum and thus is subject to translation so I > > just have to > > find why regedit displays it badly when editing the registry. Wine traces > > functions also > > but I would it is more normal. > Hmm... odd indeed I think regedit uses the ANSI codepage for the registry, while the translations are in UTF-8. I experienced this when importing .reg-files in UTF-8 with special characters in them. The umlauts in the German translation of regedit's GUI however, are displayed correctly. Is your nbsp part of the GUI or a registry-key? I would guess the second.
Spelling errors in en_US translation
Hi Francois, (and everybody else ;) are there any plans to create an ignore-list for these: http://fgouget.free.fr/wine-po/en_US.spell.html to be able to distinguish real typos from false positives? Most reported errors are false positives (like "codec" or "checksum") but there are real errors, or at least instances of uncommon spelling (like "customising", which is British English afaik, or "Cancelled") which should be fixed (after 1.4), imho. Best regards, Julian
Re: Wrong charcter encoding in winmm-tests
> So I think it's the test that should be performing the apprpriate > conversion (assuming we really care) but I can't remember the details I suppose everyone running the tests should be able to figure it out and set $LANG to en_US or something for the test. But I think this is more widespread: $ grep -d recurse "WideCharToMultiByte(CP_ACP" wine-git|wc -l 662 $ grep -d recurse "WideCharToMultiByte(CP_UTF8" wine-git|wc -l 45 > right now. In particular I'm not sure if using CP_UNIXCP would be > appropriate here. It might depend on the API used to write to stdout. > > And starting from a Unicode string would be much much better too... > (in particular for languages like Japanese, etc.) > I guess UNIXCP is the current codepage the host os uses? Like nl_langinfo(CODESET) from langinfo.h? $ grep -d recurse "WideCharToMultiByte(CP_UNIXCP" wine-git|wc -l 72 Then shouldn't most or all of those CP_ACPs (and CP_UTF8s) be replaced with CP_UNIXCP? Best regards, Julian
Re: Wrong charcter encoding in winmm-tests
OK, I think I finally found out what's going on here: in waveform.c waveOutGetErrorTextA() calls WideCharToMultiByte(CP_ACP, with the ANSI codepage. When I change that to CP_UTF8, it works as expected. Is this fix OK, or does that break anything? Should I send a patch? Thanks, Julian
Re: Wrong charcter encoding in winmm-tests
> waveOutGetErrorTextA() if I am not mistaken. Forget that part please ;) So, the .po is UTF-8, the terminal is UTF-8 and my $LANG is de_DE.UTF-8, but somewhere it is converted to 8859-1...
Wrong charcter encoding in winmm-tests
Hello everyone, I ran the winmm-tests in wine today, with a german locale, and noticed that the umlauts are displayed incorrectly. My terminal is in UTF-8 and wine outputs ISO 8859-1. I looked into the code and found out that ie. in wave.c, wave_out_error() declares the strings as static char, and thus uses waveOutGetErrorTextA() if I am not mistaken. Should this be fixed or doesn't it matter in the tests? Best regards, Julian
