From: Jiang Xin Date: Mon, 05 Mar 2012 03:01:30 GMT Subject: Re: [PATCH] i18n: Not add stripped contents for translation Message-ID: In-Reply-To: <7v7gyz7pei.fsf@alter.siamese.dyndns.org> 2012/3/5 Junio C Hamano : >> If the translations won't end with COMMA+SPACE, will break the integrity >> of the concatenate string. As for Chinese, COMMA+SPACE may translated to >> "，" -- a 3-byte UTF-8 Chinese comma character. > > Hmph. Why would that be a bad thing in the first place? Orignal source code: 244 case WT_STATUS_CHANGED: 245 if (d->new_submodule_commits || d->dirty_submodule) { 246 strbuf_addstr(&extra, " ("); 247 if (d->new_submodule_commits) 248 strbuf_addf(&extra, _("new commits, ")); 249 if (d->dirty_submodule & DIRTY_SUBMODULE_MODIFIED) 250 strbuf_addf(&extra, _("modified content, ")); 251 if (d->dirty_submodule & DIRTY_SUBMODULE_UNTRACKED) 252 strbuf_addf(&extra, _("untracked content, ")); 253 strbuf_setlen(&extra, extra.len - 2); 254 strbuf_addch(&extra, ')'); 255 } The bad thing is strbuf_setlen() at line 253. We can not asume the translation of ", " must be 2 characters. If we change line 253 like the following, it may work but introduce another string ", " for translation, and it looks weird. 253 strbuf_setlen(&extra, extra.len - strlen( _(", ") )); It is because I translate the ", " to "，" (chinese comma), the translated chinese comma is 3 bytes long, striped two of them cause the output looks weird. It is also a bug hard to detect, If a careless translater lost the end space in translation. -- Jiang Xin