Hi Paul! Le 24 sept. 2012 à 02:23, Paul Eggert a écrit :
> On 09/23/2012 12:03 PM, Akim Demaille wrote: >> Are there any evidence that there are languages in which there >> would be no possible translation like that one? > > "No possible translation" doesn't sound likely, no, as > a translator can always come up with *something*. But > it's plausible that all the possible translations would > be awkward. > > I hadn't noticed the -Wconflicts-sr versus -Wconflicts-rr > business, sorry. But in that case, how about something like > the following? > > foo.y: shift/reduce conflicts: 1 found, 2 expected [-Wconflicts-sr] > foo.y: reduce/reduce conflicts: 2 found, 0 expected [-Wconflicts-rr] (in that case that's an error, not a warning) > That's closer to the format you proposed, and it > avoids the complexity of ngettext. My point was precisely that the _translator_ can always resort to using that kind of translation; my examples were meant to show that it is certainly always possible to produce something in any language, but I used English as an example of an "any" language (No offense meant ;). So the question is rather to find something that is nice and pleasant to read for an LC_ALL=C user. My opinion as a foreigner, is that #1 below is both natural to read, and consistent (between the warning, and the error when %expect is given): #1 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr] foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr] bar.y: 1 shift/reduce conflict, expected 0 bar.y: 2 reduce/reduce conflicts, expected 0 Proposal #2: foo.y: warning: shift/reduce conflicts: 1 [-Wconflicts-sr] foo.y: warning: reduce/reduce conflicts: 2 [-Wconflicts-rr] (or with found? It avoid the ambiguous reading that "1" is sort of a conflict name, rather than a conflict count foo.y: warning: shift/reduce conflicts: 1 found [-Wconflicts-sr] foo.y: warning: reduce/reduce conflicts: 2 found [-Wconflicts-rr] ) bar.y: shift/reduce conflicts: 1 found, 2 expected bar.y: reduce/reduce conflicts: 2 found, 0 expected Given that the ngettext business is already taken care of, what do you _visually_ prefer to read? If you like #2, then let's go for it, but really for a matter of taste, not for a matter of making it easier to translate, or easier to implement (less ngettext).
