[bug #17269] localized headers in .mc/history

[Egmont Koblinger <INVALID NOREPLY gnu org>]

Follow-up Comment #4, bug #17269 (project mc):

Localizing an already localized string definitely shows wrong design.
Theoretically it can lead to false strings appearing on the screen (if the
first translated string happens to be the same as an English string used
somewhere else in mc). It's quite unlikely for this bug to ever occur, but
still it's better to avoid it by good design. It'd be bad if the person first
hitting this bug would have to choose different wording or if he had to fix mc
in this respect.

(Theoretically :-)) each function has a documented interface of what the
meaning of its arguments are, and this documentation should state for all
strings whether they are localized or not.

You say: "this may not be the best solution since the programmer must know
that it should call nice_cd () with N_() instead of _()". I think this
approach is wrong. Every programmer wishing to use an already implemented
function should first check the docs or the comments in the code to see what
this function expects and then use it accordingly. If there's no docs stating
whether the argument to nice_cd should be localized or not then _this_ is a
bug in mc. If there are docs, however, then there's nothing you can do
against wrong usage and it's not your problem anymore.

(BTW it starts resembling the usually-misunderstood Hungarian notation by
Simonyi, see:
http://www.joelonsoftware.com/articles/Wrong.html
for the right explanation. If strings are always stored in variables whose
name begins with a prefix stating whether it's already localized, to be
localized, or non-translateable, then these kinds of bugs are less likely to
occur.)

About your first suggestion: it avoids translating an already translated
string, hence it should really be done.

About your second suggestion: it could make the config file look the same
even if for some reason the English UI string is modified. Hence it is a nice
move, too.

So, I recommend making both changes :-)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?17269>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/