i18n, again: how to create base-files for i18n (previously en.js)

niko · 2005-04-07 10:42:01

as some allready may have noticed.. there are no more en.js files.
This is because when calling the HTMLArea._lc('text to translate')-function the first argument is allready the english text.

i see now two possibilities:
1. parse all source-files and find every call of _lc('')
...this gives only back a few, it will not work in:
- htmlarea.js line 447 when translating the buttons (can be easily changed)
- all dialogs using inline-dialog.js (currenlty only the linker-plugin i think)
- all dialogs using popups/popup.js __dlg_translate (most are...)

2. write a php(?)-backend that stores all requested translations into a database or a file
- some changes have to be made to the _lc-function - so that it calls the backend when a translation is not avaliable.
- you have to click through every popup in every plugin to get all strings
- what happens if strings change or get removed?

...or does anybody know a better/other solution?

thanks!
niko

gogo · 2005-04-08 02:14:03

niko wrote:

as some allready may have noticed.. there are no more en.js files.
This is because when calling the HTMLArea._lc('text to translate')-function the first argument is allready the english text.
i see now two possibilities:
1. parse all source-files and find every call of _lc('')
...this gives only back a few, it will not work in:
- htmlarea.js line 447 when translating the buttons (can be easily changed)
- all dialogs using inline-dialog.js (currenlty only the linker-plugin i think)
- all dialogs using popups/popup.js __dlg_translate (most are...)

This way should work I think, just search for _lc("....") (and with single quotes too), with <l10n>....</l10n> and _(...) for the inline-dialog html files. For the buttons, we should probably translate them when putting them into the toolbar, eg in htmlarea.js

this.btnList = {
    bold:          [ HTMLArea._lc("Bold"),   ["ed_buttons_main.gif",3,2], false, function(e) {e.execCommand("bold");} ],

The popups might be a bit more tricky

niko · 2005-04-08 03:03:22

ok, i think too that this is the better solution.
altough i might have to change all popups and add the <l10n></l10n> tags

...this would be a chance to turn all dialogs into Linker-plugin-like dialogs, what do you think?

questions about this:
- if we would do that we need a popup-dialog.js replacement for inline-dialog.js - so that everyone can decide what he wants to use
(who will write this?)
- when should the dialogs (html-files) be loaded, the linker-plugin loads the html-file when generating the editor, is it a good idea to load ALL dialogs - although the end-user might not open any dialog?

gogo · 2005-04-08 09:39:15

niko wrote:

- if we would do that we need a popup-dialog.js replacement for inline-dialog.js - so that everyone can decide what he wants to use
(who will write this?)

I would, although I havn't really thought too much about it when I hacked togethor Linker and inline-dialog, I expect it might take some work to figure it out. I don't however have very much time right now so if somebody wants to do it, by all means go ahead. What I would say is that it would be *much* preferable to use layers (eg a positioned iframe) as "faux popups" rather than real popup windows, this would be much faster to open the popups ( I find opening the dialogs quite slow at the moment) and avoid possible popup-blocker problems.

- when should the dialogs (html-files) be loaded, the linker-plugin loads the html-file when generating the editor, is it a good idea to load ALL dialogs - although the end-user might not open any dialog?

Well, two sides to the coin, if we load them at the start then it will be more responsive to users when using it, if we load the files on demand then perhaps the initial loading will be a bit faster. I prefer preloading them when starting Xinha so that it's more responsive when you want to use them, but others might feel differently. If they were loaded at the start, then they should be loaded asynchronously (ie use _getback or something) rather than hold up the rest of the process while it's loading the file from the server - see Linker for example.

niko · 2005-04-09 03:17:13

gogo wrote:

I would, although I havn't really thought too much about it when I hacked togethor Linker and inline-dialog, I expect it might take some work to figure it out. I don't however have very much time right now so if somebody wants to do it, by all means go ahead. What I would say is that it would be *much* preferable to use layers (eg a positioned iframe) as "faux popups" rather than real popup windows, this would be much faster to open the popups ( I find opening the dialogs quite slow at the moment) and avoid possible popup-blocker problems.

iframe-dialog would be the 3rd possibility (i think that one i would prefer)

One argument that would be pro-popup: the user can resize the popup!
Thats imho a big advantage for some popups (most are currenlty fixed-size anyway) - but if you use the linker-plugin with a huge tree - why not make it a resizeable popup?

just an idea:
wouldn't it be possible to make fast popups by opening a "about:blank"-popup and then write the html-code into it? (that might be allready preloaded)

If they were loaded at the start, then they should be loaded asynchronously (ie use _getback or something) rather than hold up the rest of the process while it's loading the file from the server - see Linker for example.

...i didn't look at that in detail - does that really work? can i work with the editor while in background the linker-dialog gets loaded?
if this is the case and makes no problems... why not - the only argument against it would be that xinha requested uneccessary files from the server.

gogo · 2005-04-11 22:07:13

wouldn't it be possible to make fast popups by opening a "about:blank"-popup and then write the html-code into it? (that might be allready preloaded)

No, I mean the actual action of creating the popup window is quite slow, once it's open it doesn't matter how the content gets into it. Displaying a layer/iframe is much much quicker (and memory friendly) than opening a window.

i didn't look at that in detail - does that really work? can i work with the editor while in background the linker-dialog gets loaded?

To tell you the truth, I don't actually know. The transfer should be asynchronous, so actually downloadin the data from the server should work "in the background", but I expect that actually manipulating that data happens in the foreground (ie all Javascript within a window runs in a single thread), otherwise it would mean that the JS engine would have to multi-threaded, and I'm pretty sure that it's not.

Xinha Discussion Forum

Announcement

#1 2005-04-07 10:42:01

i18n, again: how to create base-files for i18n (previously en.js)

#2 2005-04-08 02:14:03

Re: i18n, again: how to create base-files for i18n (previously en.js)

#3 2005-04-08 03:03:22

Re: i18n, again: how to create base-files for i18n (previously en.js)

#4 2005-04-08 09:39:15

Re: i18n, again: how to create base-files for i18n (previously en.js)

#5 2005-04-09 03:17:13

Re: i18n, again: how to create base-files for i18n (previously en.js)

#6 2005-04-11 22:07:13

Re: i18n, again: how to create base-files for i18n (previously en.js)

Board footer