savannah: localized headers in .mc/history

[egmont]

Original: ​http://savannah.gnu.org/bugs/?17269

Submitted by:	Egmont Koblinger <egmont>	Submitted on:	Wed 02 Aug 2006 12:48:15 PM UTC
Category:	Core	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	current (CVS or snapshot)	Operating System:	GNU/Linux

Original submission:

.mc/history contains headers like this:
[inp Kijelölés ]
[inpÚj könyvtár létrehozása]
and so on...

Localizing these entries may cause troubles:
- entries in the history are not available if for some reason you 
temporarily start mc with another locale
- entries get lost if mc is upgraded and the translators happened 
to modify the translation

Headers in the history file should be fixed (non-translateable) 
English strings. 

Comment 1 by Leonard den Ottolander <leonardjo> at Wed 02 Aug 2006 01:18:32 PM UTC:

I agree with this. Can you come up with a patch?

Comment 2 by Egmont Koblinger <egmont> at Wed 02 Aug 2006 02:09:08 PM UTC:

Maybe once... not now, I don't have time for this nowadays.

Comment 3 by Pavel Tsekov <ptsekov> at Wed 13 Sep 2006 09:28:22 AM UTC:

I looked at that problem and the solution is pretty easy. Still I'd 
like to discuss the issue with anyone interested so we can find the 
best way to solve the problem.

Most of the problematic entries are created by an invocation of the 
function nice_cd() located in src/cmd.c . Its first argument is a 
string to be used as the heading of the dialog. The same string is 
also used to form the name of the section in the history file where 
entries fed to the input field of the dialog will be stored. A 
typical call to nice_cd() looks like this:

nice_cd (_("Title string"), ...)

So as you can see nice_cd() is passed a translated string - this is 
why a translated section name is written to the history file. 
However this is unnecessary since later the title string is 
translated one more time when quick_dialog() is invoked to show the 
dialog. So, one way to solve the problem is to change nice_cd() 
invocations like this:

nice_cd (N_("Title string"), ...)

However, this may not be the best solution since the programmer 
must know that it should call nice_cd () with N_() instead of _(). 
So, maybe a better way to solve the problem would be to add

a new argument to nice_cd() which will hold the history section name.

Any thoughts ?

Comment 4 by Egmont Koblinger <egmont> at Wed 13 Sep 2006 10:00:24 AM UTC:

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 :-)

Comment 5 by Pavel Tsekov <ptsekov> at Wed 13 Sep 2006 12:38:16 PM UTC:

My last comment may be slightly misleading. To clarify:

nice_cd() and others use fg_input_dialog_help() which takes
care of displaying the input dialog and derives history file
section names from the input dialog heading.

Comment 6 by Pavel Tsekov <ptsekov> at Wed 13 Sep 2006 01:55:14 PM UTC:

I think I'll proceed as following:

1) Currently fg_input_dialog_help() assumes that it is passed 
translated strings. I won't change that because some of the callers 
pass as an argument a string which is the result of sprintf() on 
translated template string. However, I'll change
fg_input_dialog_help() to prevent the translation of the already 
translated strings. Additionally I'll add comments to indicate that 
fg_input_dialog_help() and any wrappers must take translated 
strings.

2) Next I'll change fg_input_dialog_help() to take a new argument
- the history section name. Then I will adjust all callers.

Comment 7 by Pavel Tsekov <ptsekov> at Tue 19 Sep 2006 08:24:44 AM UTC:

I am attaching a patch which adds a new argument to 
fg_input_dialog_help() - the history section name. I've adjusted 
all callers (hopefully) to pass the new argument. Please, test the 
patch. The patch should be applied against latest CVS.

This patch doesn't attemt to change the section names. However, the 
current choice for section names is really bad, IMHO. Maybe now is 
the time to rename those names for good. I'd like to hear your 
opinion on that matter too.

committed to master:

changeset:7cef5b112ea9015422882a070fa12a01c23ce5a5

[slavazanko]

added by ptsekov

[winnie]

I think this should also be fixed in a 4.6.2 release

[metux]

Another way would be storing them exclusively in utf8

[winnie]

any idea how to solve this in order to make the change so that they customisations are not lost between 4.6.1 and 4.6.2.

One option would be in my eyes to write a small function which is executed if not certain headers are found in the configuration file. which will then read all values and backup the file to some place and write a new one with the static values.

The other way would be much easier.. but also much more annoying for the endusers.. switch the behaviour and backup the configuration file in order there are notreadable values in it (and notify the user about this of course) so that the user can copy his customisations manually from the old file to the new one.

[winnie]

Added branch 50_history_section_names.. Please review..

While reviewing this patch we also should think about a renaming of this section as Pavel suggested above. (In the text copied from savannah).

Please discuss better fitting strings here.

[slavazanko]

I propose make names of sections with function name as prefix string. This will provide a unique names of sections.

For example:

[inp:mc_mkdir Enter directory name ]
0=...
1=...

See changeset:22fada9ce0f6493d9f33ce4d4a3f31338564fa55

[metux]

Please also have a look at my branch:

50_history_sections.metux

[winnie]

/me really likes the metux branch, therefore I vote for it.

[slyfox]

50_history_sections.metux

look really good.

As we updated (git log origin/mc-4.6 --stat po/) - many files are already changed therefore make non-english users to lose their ~/.mc/history, so break it once again to make stable.

[winnie]

Please add a changelog entry!!! This is an important change which is currently not documented in the ChangeLog?!

[winnie]

I've already added a changelog entry.

Before the release we should update the NEWS file to reflect every change we've done so far for 4.6.2