On Sat, Feb 9, 2013 at 1:03 PM, Lauri Kenttä lauri.kentta@gmail.com wrote:
Change labels in UDP statistics so that they better reflect the actual meanings as described in MSDN [1].
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366929%28v=vs.85%2...
- IDS_UDP_NO_PORTS, "No Ports"
- IDS_UDP_RECV_ERRORS, "Receive Errors"
- IDS_UDP_NO_PORTS, "Invalid Port Errors"
- IDS_UDP_RECV_ERRORS, "Invalid Datagrams" IDS_UDP_DGRAMS_SENT, "Datagrams Sent"
"Invalid Datagrams" is too vague. It could mean datagrams sent or received.
If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating
Frédéric
On 2013-02-09 23:15, Frédéric Delanoy wrote:
"Invalid Datagrams" is too vague. It could mean datagrams sent or received.
I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it.
On 2013-02-09 23:15, Frédéric Delanoy wrote:
If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating
This isn't (only) a translation ambiguity issue, this is about the original texts, especially "No Ports".
Or are you trying to suggest that I add #msgctxt#udp_received_stats# to that "Invalid Datagrams"?
On Tue, Feb 12, 2013 at 7:56 PM, Lauri Kenttä lauri.kentta@gmail.com wrote:
On 2013-02-09 23:15, Frédéric Delanoy wrote:
"Invalid Datagrams" is too vague. It could mean datagrams sent or received.
I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it.
Yet it's what Windows uses, and is more specific, so I don't really think this should modified
On 2013-02-09 23:15, Frédéric Delanoy wrote:
If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating
This isn't (only) a translation ambiguity issue, this is about the original texts, especially "No Ports".
Or are you trying to suggest that I add #msgctxt#udp_received_stats# to that "Invalid Datagrams"?
I meant if you find a msgstr ambiguous(which is not really a problem for the "No ports" IMHO), you can use msgctxt so that other translators benefit as well.
Frédéric
On 2013-02-13 11:03, Frédéric Delanoy wrote:
On Tue, Feb 12, 2013 at 7:56 PM, Lauri Kenttä lauri.kentta@gmail.com wrote:
On 2013-02-09 23:15, Frédéric Delanoy wrote:
"Invalid Datagrams" is too vague. It could mean datagrams sent or received.
I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it.
Yet it's what Windows uses, and is more specific, so I don't really think this should modified
Ok, I'll leave it alone.
On 2013-02-13 11:03, Frédéric Delanoy wrote:
I meant if you find a msgstr ambiguous(which is not really a problem for the "No ports" IMHO), you can use msgctxt so that other translators benefit as well.
My main point is that "No Ports" is not only ambiguous but also wrong in two ways.
Bad wording: Why "ports" and not only "port" when this only concerns the single destination port of each datagram? How can there not be a port when the datagram always has a port field which can't be empty? (The RFC says that zero means empty only in the source port field, which implies that zero could be a valid destination.)
Bad meaning: dwNoPorts actually includes also datagrams with non-zero port if the port is closed (not listening). MSDN hints something like this, and this can be easily verified on Windows (2003 Server).
Ambiguity: There are many kinds of "no" and many kinds of "ports", and most people (even programmers!) probably don't know what's a datagram with "no ports". Also, translating "X" is quite different from translating "number of received datagrams with X", even more so when the source text is inaccurate.
Windows has lots of bad texts, I hope Wine doesn't need to provide "compatibility" for that. But if you still say so, I'll just add a msgctxt.