[BUG/REQ] Content plugin translation only works when...

[icfu]

...language file adheres to the following naming scheme:

Code: Select all

WCMD_XYZ.LNG

The trigger for this autodetection is the line

Code: Select all

LanguageIni=WCMD_XYZ.LNG

in wincmd.ini.

When you change that line to something like

Code: Select all

WCMD_XYZblablablubb.LNG

because your language file is named like that, it won't work anymore and content plugins will load with default language English.

The reason I am using different language files (with same content) is because I am using different menu files. When both language file and menu file have the same name, TC language dialog is able to automatically choose the corresponding menu file when choosing a language file.

So, here is the request:
Ignore everything that follows after XYZ and limit the detection only to the WCMD_XYZ part!

Icfu

[Clo]

Hello Jeff !

• Right, this is very annoying…

- I noticed this while testing the TotalSQX plugins.
- We had even a problem this the case, that seems strange, but true (fixed up now, fortunately)

- I've been bound to use the native name for my customized LNG+MNU, and rename the original files (I don't use, but useful to check when someone is talking of on the forum).

- I guess that the author could set a rule for the plugins authors like :
WCMD_XYZ_customizationID.LNG
WCMD_XYZ_customizationID.MNU
making that as soon as a second underscore "_" is found, that underscore and any string which follows it be ignored…

 VG
Claude
Clo

[icfu]

- I guess that the author could set a rule for the plugins authors like :
WCMD_XYZ_customizationID.LNG
WCMD_XYZ_customizationID.MNU
making that as soon as a second underscore "_" is found, that underscore and any string which follows it be ignored…

Sure, this would be an option, but what would be the benefit? The stuff behind XYZ can be ignored anyway, without the need for an additional underscore, because WCMD_XYZ is a sufficient condition to exclude wrong matches of XYZ in the filename, isn't it?

Icfu

[Sheepdog]

Full support.

But regarding to the languagefiles Wcmd_sk.lng and Wcmd_cz.lng it seems to be necessary to use only the first two chars of the language filename. This would currently not lead to any problems:

Code: Select all

WCMD_CZ.LNG
WCMD_DA.LNG
WCMD_DE.LNG
WCMD_DU.LNG
WCMD_ES.LNG
WCMD_FR.LNG
WCMD_HU.LNG
WCMD_IT.LNG
WCMD_KO.LNG
WCMD_NO.LNG
WCMD_PO.LNG
WCMD_SK.LNG
WCMD_SV.LNG
WCMD_SW.LNG

and would only require to make the country code added in future distinguishable by the first two chars (what should be no problem).

sheepdog

[Clo]

2Sheepdog
Hi Stefan !

- Your remark about the two-character ID sounds logical, so my proposal for a "_" separator makes more sense in this case…

…(what should be no problem).

- I'm not as so sure as you ! In another programme, we had an issue with i.e. “…UK.ext” for (English) UK, and the same for UKrainian !
- Using three characters, this can be solved easily…
- The current syntax is not very coherent, IMHO… I think that we might have always three characters as ID, this is not a big deal to add a third one for all languages, except if we'ld have a language so-named “YO" only, no more
- But in that case, it's still possible to add a "wildcard" planned character, like "_" or "~" or whatever else…

  VG
Claude
Clo

[Sheepdog]

Hello Claude,

I think one could use the Top Level Domain Extensions used for the internet. That's what I had in mind. Here you would use for Ukraine ua. The english site in the wiki hasn't such a nice list with Country - Countrycode, that's why I linked to the german one.

so my proposal for a "_" separator makes more sense in this case…

I think it is much easier to restrict the check to the first 7 chars of the string than to implement a search for the underscore. So I support icfus proposal.

sheepdog

[Jungle]

i suppose ID should be the fist chars. Plus little description inside the files in order not to be confused.
for example:

Code: Select all

filenames:
eng_my_ui_name.lng
eng_my_menu_name.mnu

Code: Select all

[id]
lang_name=English
info=Alternative english interface v1.0
auth=Some user

the same applies to menu
file. so in the options dialog we'd see:

Code: Select all

English: Alternative english interface v1.0 (by Some name), [menu info], ([filenames])

[Sheepdog]

2Jungle
We don't talk about redesign of the language and menu management but a little improvement of the currently used (that works pretty well so far IMHO).

From "Help for Content Plugin Interface"

Translation of content plugins is quite easy: Just create a text file with the same name as the content plugin, but with extension lng. Example: contentplug.wdx -> contentplug.lng.

snip

This lng file contains a separate section for each language, with the same name as the language part of the main Total Commander translation files. Example wcmd_deu.lng -> section [deu] for German (called "Deutsch" in German).

But if my specila menus name is wcmd_deu_sheepdog.lng I have to rename all plugins language files to contentplug_sheepdog.lng.

If the Plugin interface would evaluate only the wcmd_deu.lng part the renaming would be unnecessary.


sheepdog

[icfu]

@Sheepdog:
I like the idea because it's always good to use a decent standard to do things.

@Jungle:
This thread is about content plugins translation and the detection of the language by the language file reference in wincmd.ini, not about redesigning of TC language/menu files!

Besides that you can already add whatever info you like in first line of TC language file and it will show up in options dialog...

Although you can open a separate thread with your request, the next bigger goal to achieve is the Unified Command System:
http://www.ghisler.ch/wiki/index.php/Unified_Command_system

Icfu

[Lefteous]

It's not really necessary to create redundant language files. There is also a >> button to change the menu file - two more clicks.

[icfu]

I don't think that any noobs are reading this thread that need info on how to choose menu files manually...

Furthermore I have explained above:

The reason I am using different language files (with same content) is because I am using different menu files. When both language file and menu file have the same name, TC language dialog is able to automatically choose the corresponding menu file when choosing a language file.

Icfu

[Sheepdog]

It's not really necessary to create redundant language files. There is also a >> button to change the menu file - two more clicks.

That makes automatic language changes much more inconvenient. Now I have an Autohotkey Script that allows me to choose the menu with choosing the language file - and that with one key.

With your "Two more clicks" solution I would have to select both, the menu file and the language file.

Because I can use an english menu with german Language file selected. But this is not what I would like to.


sheepdog

[Lefteous]

2Sheepdog

That makes automatic language changes much more inconvenient. Now I have an Autohotkey Script that allows me to choose the menu with choosing the language file - and that with one key.

With your "Two more clicks" solution I would have to select both, the menu file and the language file.

Because I can use an english menu with german Language file selected. But this is not what I would like to.

Well I'm sure you can do a auto hotkey script for the "two more clicks" solution.

[icfu]

Of course, you can also bake a pizza with a toaster.
The question is: Why do that when you have an oven?

Icfu

[Sheepdog]

Well I'm sure you can do a auto hotkey script for the "two more clicks" solution.

What for?

To make it more probable that something's going wrong with the script?

sheepdog