Ticket #158 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

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

Reported by: anonymous Owned by: gogo
Priority: high Milestone:
Component: Plugin_Linker Version:
Severity: normal Keywords: language
Cc:

Description

in the context-menu.js for example

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

change to

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

for the language translation!

Attachments

context-menu.js (15.4 kB) - added by gocher / udo.schmal@… 8 years ago.
everything changed

Change History

Changed 8 years ago by gocher / udo.schmal@…

everything changed

Changed 8 years ago by niko

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

Changed 8 years ago by 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.

Changed 8 years ago by 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...

Changed 8 years ago by 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];
  }
}

Changed 8 years ago by 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...

Changed 8 years ago by 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

Changed 8 years ago by 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)

Changed 8 years ago by 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.

Changed 8 years ago by 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

Changed 8 years ago by niko

  • status changed from new to closed
  • resolution set to fixed

commited in changeset:97

Changed 7 years ago by anonymous

  • status changed from closed to reopened
  • resolution deleted
  • component changed from Xinha Core to Plugin - Linker

Changed 7 years ago by anonymous

  • status changed from reopened to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.