The following message is a courtesy copy of an article
that has been posted to gmane.comp.version-control.git as well.
Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Sun, Dec 8, 2013 at 9:11 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
>> I could fix vi.po alone, but it'd be better to avoid similar mistakes
>> for all translations by moving the trailing space out of all
>> translatable strings (*). This is inline with how we handle newlines
>> (e.g. *printf_ln wrappers) but it's not widespread enough to make new
>> *printf_space wrappers.
>
> And I just realized spaces are more common in languages using latin
> alphabet but are not a rule. CJK languages do not have/need spaces so
> this might be a wrong move..
There are already other issues as well. The strings also seem to be
assuming certain word orders. For example:
> - on_what = _("HEAD detached at ");
> + on_what = _("HEAD detached at");
Both versions of this assume that the location at which HEAD was
detached should come at the end of the sentence, whereas in
rightward-headed languages such as Japanese it would be more natural to
put the location at the middle or beginning of the sentence (while it is
possible to rewrite the text a bit to force the location to come at the
end).
I think the best practice is to just have one long string per "message"
the program is supposed to display, and only display that string with %s
substituted for data, rather than printing that string and then printing
the data, or printing the data and then printing the string, or
whatever. With printf() in C, the %s can even be reordered wrt to the
calling order with a special syntax, "%m$", if necessary, as I just
learned from `man 3 printf`...
-Keshav
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html