HTMLArea._lc mistakes in plugins\ContextMenu\context-menu.js

[anonymous]

in the context-menu.js for example

HTMLArea._lc("Modify Link", "ContextMenu")

change to

HTMLArea._lc("_Modify Link...", "ContextMenu")

for the language translation!

[gocher / udo.schmal@…]

everything changed

[niko]

hmm... if i apply this all existing translations will be broken! the translation might have to be adapdet

[mokhet]

you dont gonna like what i'm about to (try to) say, but yes the actual _lc() system got something wrong. We cant play with the english texts anymore unless we change htmlarea.js . Which is bad, very bad.

With the old en.js, we only had to manually update this file and automatically update the svn version. Now, we cant update texts anymore and i know i have customers wanting some specific texts. Yes i know it's dumb but it's something asked a lot. Every customers always want their own little way to write things. They dont want the text "Font Color", they want "Color", but another want "Text color", etc. Yes i'm agree, it's dumb :( but i cant use my energy to fight against such things

The only way would be to bring back all the en.js but i dont think it's something you want to do.

But the worst side of the actual _lc() is, as shown in this ticket ,the fact that once we have a text in the plugin or core editor, we are stuck with it or we break translation everytime.

Hope you dont misunderstand me, the _lc() work is great, but it has a bad side we starting to see (digging ? :) and i think we will see more and more issue around this, unfortunatly.

[niko]

hmm... i get your point... but why don't you create your own language-file where just the few thinks are changed that you need changed?

But the worst side of the actual _lc() is, as shown in this ticket ,the fact that once we have a text in the plugin or core editor, we are stuck with it or we break translation everytime.

yes... thats true... a solution would be to create a simple script that does such a convertion... (would be not too hard...)

Actually i plan to create a script that parses all js-files for a _lc() and adds the strings found there to the language-file. But it will take some time till this is finished...

[mokhet]

but why don't you create your own language-file

that's what I am doing :) and it does the job perfectly eheh

plan to create a script that parses all js-files for a _lc() and adds the strings

I dont understand how it could fix the problem ? It's not a problem found only in the core editor, every plugins are affected. That's means translators got the dig into a lot of files for each plugin (depends on complexity) when one is updated, to finally recompile all the _lc() found in one single file. It can get worst when dynamic content is used (button name in icon bar for instance).

Without a language file as a reference, it's really stopping translation, or at least it's slowing it. At least for me it is slowing it down a lot. When there was an en.js to refer, it was easy and doesnt need real javascript skills to do the job and propose an updated version to the community.

I think the best solution would be to reintroduce every en.js and keep the wonderfull job provided by _lc(). Just by removing if(_editor_lang == "en") { return string; }

/** Return a localised string.
 * @param string    English language string
 * @param context   Case sensitive context name, eg 'HTMLArea' (default), 'TableOperations'...
 */
HTMLArea._lc = function(string, context)
{
  if(typeof HTMLArea._lc_catalog == 'undefined')
  {
    HTMLArea._lc_catalog = [ ];
  }

  if(typeof context == 'undefined')
  {
    context = 'HTMLArea';
  }

  if(typeof HTMLArea._lc_catalog[context] == 'undefined')
  {
    HTMLArea._lc_catalog[context] = HTMLArea._loadlang(context);
  }

  if(typeof HTMLArea._lc_catalog[context][string] == 'undefined')
  {
    return string; // Indicate it's untranslated
  }
  else
  {
    return HTMLArea._lc_catalog[context][string];
  }
}

[niko]

yes, that would be a possibility too! but i don't know if this is a really good one....

i mean, if you have an incomplete translation, the default english-text should be used - meaning the argument from the _lc-call.

But if we do it like you suggest - the english-text would be different from the text in the _lc-calls!

we would have to load en.js too - for all untranslated strings!

...as gogo came up with the whole idea of the new i18n-system (i only implemented it) - i think he should decide how to proceed here...

[mokhet]

honestly, i dunno what is the best idea neither i can say what's the best way to implement it. I understand perfectly your point and i'm not trying at all to make you change your mind about the whole system, just trying (and hoping you do) to let you understand the difficulty it is for a non javascript specialist to contribute to the project as a simple translator.

I think the actual _lc() system got two flaws

1) needs some javascript skills to understand how and what to translate 2) there is no way to know if the language file is up to date or totally outdated

[niko]

1) here i could imagine a little (database-driven) php-script on the official xinha-page (or somewhere else) where you and others can easy translate. using another script we can generate the langauge-files out of the database.

2) my plans are to create another script that makes a template-language-file - with all entries that can be translated (it parses all js-files)

to get to 2) we need to change the popups to a more generic way... i'm working on something here too (it seems that i'm working on too much :D)

[kim@…]

Creating a PHP script which scans through all .js files and picks out all the ._lc occurencies isnt a big job, I could easily create such a script. The other problem I noticed, (I might be wrong here), is that some scripts eg. the Linker plugin, has more translating than the .js file has ._lc. I guess there are some DOM traversing in replacing something, or maby I only need to look more into the code.

If all that is needed is a ._lc regex to pick out the stuff, than give me a poke in the back and I'll put together some PHP lines to do the work.

[niko]

yes, this would be nice!

• scan all *.js for ._lc
• scan all *.html for <l10n>blah<l10n> (currently only plugins/Linker/dialog.html)
• scan all *.html for _(blah) (currently only plugins/Linker/dialog.html)

in htmlara.js line 363 best would be to add the _lc-call directly here, not in line 455

[niko]

commited in changeset:97