[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Messages should not contain the `\v' escape?
From: |
Bruno Haible |
Subject: |
Re: Messages should not contain the `\v' escape? |
Date: |
Fri, 8 Sep 2006 18:39:50 +0200 |
User-agent: |
KMail/1.9.1 |
Sergey Poznyakoff wrote:
> In some cases messages could legitimately contain the '\v' escape. One
> of such cases is the use of GNU argp_parse function, for which this
> character means "output the following text after the list of the
> options". The GNU projects using this feature include: tar, cpio,
> radius, mailutils and cflow. If there are no strong reasons against
> allowing the use of `\v', I'd propose the following change:
>
> Index: gettext-tools/src/write-po.c
> --- gettext-tools-orig/src/write-po.c 2006-09-08 18:39:28.000000000 +0300
> +++ gettext-tools/src/write-po.c 2006-09-08 18:20:31.000000000 +0300
> @@ -603,7 +603,7 @@ wrap (const message_ty *mp, FILE *fp, co
> *op++ = UC_BREAK_PROHIBITED;
> /* We warn about any use of escape sequences beside
> '\n' and '\t'. */
> - if (c != 'n' && c != 't')
> + if (c != 'n' && c != 't' && c != 'v')
> {
> char *error_message =
> xasprintf (_("\
>
There are strong reasons against it. It was already discussed in
the thread starting at
http://lists.gnu.org/archive/html/bug-gnu-utils/2006-08/msg00026.html
I'm adding the following to the GNU gettext documentation.
Bruno
*** gettext.texi 28 Aug 2006 13:35:56 -0000 1.105
--- gettext.texi 8 Sep 2006 16:36:39 -0000
***************
*** 1630,1635 ****
--- 1630,1638 ----
@item
Use format strings instead of string concatenation.
+
+ @item
+ Avoid unusual markup and unusual control characters.
@end itemize
@noindent
***************
*** 1849,1854 ****
--- 1852,1883 ----
String.Format("Replace @address@hidden with @address@hidden", object1,
object2));
@end example
+ @cindex markup
+ @cindex control characters
+ Unusual markup or control characters should not be used in translatable
+ strings. Translators will likely not understand the particular meaning
+ of the markup or control characters.
+
+ For example, if you have a convention that @samp{|} delimits the
+ left-hand and right-hand part of some GUI elements, translators will
+ often not understand it without specific comments. It might be
+ better to have the translator translate the left-hand and right-hand
+ part separately.
+
+ Another example is the @samp{argp} convention to use a single @samp{\v}
+ (vertical tab) control character to delimit two sections inside a
+ string. This is flawed. Some translators may convert it to a simple
+ newline, some to blank lines. With some PO file editors it may not be
+ easy to even enter a vertical tab control character. So, you cannot
+ be sure that the translation will contain a @samp{\v} character, at the
+ corresponding position. The solution is, again, to let the translator
+ translate two separate strings and combine at run-time the two translated
+ strings with the @samp{\v} required by the convention.
+
+ HTML markup, however, is common enough that it's probably ok to use in
+ translatable strings. But please bear in mind that the GNU gettext tools
+ don't verify that the translations are well-formed HTML.
+
@node Mark Keywords, Marking, Preparing Strings, Sources
@section How Marks Appear in Sources
@cindex marking strings that require translation