[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r38199 - in trunk/subversion: libsvn_client libsvn_wc

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Mon, 29 Jun 2009 08:53:13 -0500

On Jun 29, 2009, at 8:42 AM, Arfrever Frehtes Taifersar Arahesis wrote:

> 2009-06-25 16:47 Hyrum K. Wright <hyrum_at_hyrumwright.org> napisaƂ(a):
>> Author: hwright
>> Date: Thu Jun 25 07:47:23 2009
>> New Revision: 38199
>> Log:
>> Remove some "format not a string literal, argument types not
>> checked" warnings,
>> and simplify a few format strings while we're at it.
>> * subversion/libsvn_wc/update_editor.c
>> (window_handler, apply_textdelta, close_file),
>> * subversion/libsvn_wc/questions.c
>> (compare_and_verify),
>> * subversion/libsvn_wc/adm_crawler.c
>> (svn_wc_transmit_text_deltas2),
>> * subversion/libsvn_client/export.c
>> (close_file):
>> Don't dynamically build error format strings, when they can just
>> as
>> easily be indicated statically.
> Could you revert this change? Separation of " expected: %s" and "
> actual: %s" messages allows to avoid the risk of inconsistent
> translation of these messages and also reduces the amount of text
> which need to be translated.

It seems there is a tradeoff to be made here: Compilation warnings
every time somebody compiles (and a slight runtime cost of allocating
an separate format string when these errors occur) vs. a n-time
translation cost for translators. Now, since I'm not a translator, I
don't feel that pain very acutely, but it seems that a one-time
translator cost is much more reasonable than a every-compile-time
developer cost.

I also don't quite understand what the "risk" involved with
inconsistent translation of these messages is. To help me better
understand the translator's plight, could you elaborate? Do other
translators have a feeling on this as well?


Received on 2009-06-29 15:53:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.