Translator_XH

[cmb]

Hello community,

I've just released Translator_XH 1beta1. It's available from my website.

Translator_XH is an advanced tool for translating the CMSimple core, pluginloader and individual plugins. It's partcularly useful for translators, so the typical end-user of CMSimple does not have any need for this plugin.

The current version has to be considered Beta software! Use with caution!

Any feedback is welcome -- particularly about missing features, or functionality that could be improved.

Christoph

[Tata]

Seems really excellent. One more idea (as always ). How about to make the output of

Code: Select all

.../?&translator&admin=plugin_main&action=plugin_text...

linkable. I mean, if the translator has all language-files translated and ready for evtl. download, a link to each translated file would be available. Or does it conflict with any security issues?

[cmb]

Hi Tata,

I mean, if the translator has all language-files translated and ready for evtl. download, a link to each translated file would be available.

Do you mean a download-link for the translator (that's already possible with the "download" button), or for end-users? About the latter case: I'm not quite sure, if that is a good idea. IMO it is better to provide the downloads from another folder than the plugin folders (perhaps downloads/), and with a name including the version number. This can't be done automatically.

But what about this alternative: instead of the download button, a save button is available. When clicking the save button a name for the language pack must be entered, and then the language pack is saved in a configurable folder.

Christoph

[Tata]

...a save button is available. When clicking the save button a name for the language pack must be entered, and then the language pack is saved in a configurable folder.

This would be fine. I just think about some way of standardisation of the translation procedure ending with a standard defined download link. Maybe I miss some point. But I thought about:
1. Listing of all installed plugins - solved excellently
2. Two columns source/target languages - solved excellently - I tried to add labels before flags using new variables (not important):

Code: Select all

//***
$plugin_tx['translator']['translate_from']="Translate from";
$plugin_tx['translator']['translate_to']="Translate to";
//***

3. Save button to save translated file to its basic location - solved excellently
"As a cherry on the cake top"
4. MakeLanguagePack button to save translated file with its root-relative paths and evtl. ZIP them under the given name. If the "version" variable would become the standard for plugins/addons developers, then the name of the ZIP could be IMHO generated automatically.
5. Code-box with the URL to the language pack to copy/paste on any other place on internet.

[cmb]

Hello Tata,

I tried to add labels before flags using new variables (not important):

Change admin.php, line 272ff:

Code: Select all

    $$lang_h = file_exists($fn)
        ? $$lang.' '.tag('img src="'.$fn.'" alt="'.$$lang.'" title="'.$$lang.'"')
        : $$lang;    
 

I will do this for the next version.

MakeLanguagePack button to save translated file with its root-relative paths and evtl. ZIP them under the given name.

Indeed that seems to be better than the current solution "download language pack". I'll make it so.

If the "version" variable would become the standard for plugins/addons developers, then the name of the ZIP could be IMHO generated automatically.

You're right. And even other things could be improved regarding the management of plugins, if a standard would be agreed upon. But one problem remains: how to handle the base language pack (core, pluginloader and default plugins)?

Code-box with the URL to the language pack to copy/paste on any other place on internet.

This could be easily displayed directly after saving, because the name is known then. But to show it permanently the names of the saved language packs must be stored somewhere.

Christoph

[Tata]

Change admin.php, line 272ff:

Code: Select all

    $$lang_h = file_exists($fn)
        ? $$lang.' '.tag('img src="'.$fn.'" alt="'.$$lang.'" title="'.$$lang.'"')
        : $$lang;    
 

I used this

Code: Select all

$htm .= '<tr><th></th><th>'.$plugin_tx['translator']['translate_from'].': '.$from_h.'</th><th>'.$plugin_tx['translator']['translate_to'].': '.$to_h.'</th></tr>'."\n";

[ external image ]

...But one problem remains: how to handle the base language pack (core, pluginloader and default plugins)?...

The question is - What would be better/easier for endusers/translators?
- download LanguagePackCMSimple_XH_xx_yyyymmdd.zip structure with all actual language files and use/upload/install only those needed
- look only for for those needed and download/upload/install them separately

This could be easily displayed directly after saving, because the name is known then. But to show it permanently the names of the saved language packs must be stored somewhere.

1. The translator may define the folder for storing the ZIPs easily - e.g. userfiles/translations - this can be even be defined in plugin's config.
2. The path will be used with "ZIP"-button anyway. Or the button may be extended by an file-name-box and an URL-box appearing after saving as "read-only" with the full URL to the ZIP file.
Before saving:
[ external image ]
after
[ external image ]

[cmb]

Hi Tata,

thanks for the detailed reply and the screenshots, which make things clearer for me.

I used this

Ah, now I understand. That's a good idea.

The question is - What would be better/easier for endusers/translators?

IMO the language packs for the base distribution of CMSimple_XH should contain all necessary language files (core + pluginloader + default plugins) for 1 language. I thought, that other plugins should contain all available language files in their download, as it is the case now. But perhaps that should be changed too.

The translator may define the folder for storing the ZIPs easily - e.g. userfiles/translations - this can be even be defined in plugin's config.

That's reasonable.

Or the button may be extended by an file-name-box and an URL-box appearing after saving as "read-only" with the full URL to the ZIP file.

Something like this I had in mind. But I'm not sure, if the full URL is necessary/reasonable, or if the relative path is perhaps better.

And I'm currently not sure how to handle the problem of an already existing language pack with the same name. Should it be simply overwritten?

Christoph

[Tata]

...But I'm not sure, if the full URL is necessary/reasonable, or if the relative path is perhaps better...

Depends of the way the link will be used. If the link shall be used e.g. here in forum, the relative path won't work. WIll it?

And I'm currently not sure how to handle the problem of an already existing language pack with the same name. Should it be simply overwritten?

Again the question: If a file already exist, what is the reason for its new translation/editing? Maybe some additional change, new variable added, some misspelling found... Whatever is the reason, translated/edited file is the last actual version. In this case the overwritten file is OK. Or the name may be generated the same way like the content/pagedata files (name_yyyymmddhhmmss).

[cmb]

Hi Tata,

If the link shall be used e.g. here in forum, the relative path won't work. WIll it?

I don't know if the link will be used here in the forum, but probably an absolute is better after all. If only the relative URL is needed, the user can only copy this part.

Whatever is the reason, translated/edited file is the last actual version

I've thought about different language packs for different versions of CMSimple resp. plugins. But in this case the translator should give a different name to the language pack -- so simply overwriting an already existing file should be okay.

Christoph

[Tata]

But in this case the translator should give a different name to the language pack...

Now I even think about some hard coded file-name-mask with mandatory language code in it. This way all languagepacks would use the same naming convention.
The mask example (hard cocded / mandatory / generated):
LanguagePack_CMSimple_XH_xx_SK_20111103_181030.zip
LanguagePack_CMSimple_XH_pluginloader_xx_SK_20111103_181050.zip