87 replies to this topic

[Goofy]

This new topic is dedicated to the work on Davide Ficano's Externalize extension. This very good tool was originally requested by me (see on this topic ) and I tested it successfully since May '06 on more than 45 extensions which were lacking a locale structure, a good number of them were submitted on BZ by their devs afterwards (see this topic of the moderators corner)
I also began a babelwiki page which is uncomplete and needing screenshots among others.



Good news are coming. Dafi has now some time to spare on this extension. Just to remember, I put here some kind of wishlist by order of priority (imho) :


[color=#FF0000]* trim the length of the created entities to a customized number of characters. In the current version there is manual work to limit the length to something reasonable. So the entitizing process itself is very quick and spares much time, but you have to check every file afterwards for empty strings and too long entity names.
* add the extension name (or first chars of it) at the beginning of entity names (as it is common use for most of manually created entities)
* detect empty strings from the xul files and avoid creating empty useless entities
* make the .txt files editable and customizable throughout the extension interface
* fix a kind of mess that may happen when creating the doctype line in case there already is one (a "public" one, referring to FF chrome itself)
* add an extra dialog popping when a file is processed, telling "Strings from this file are now successfully entitized, do you want to process another file ? (Y/N)" . When there are numerous files to "externalize", user has to restart the main dialog for each file, it would be quicker to leave the main dialog (file selector) open as long as there are files to process

[dafi]

I put here some kind of wishlist by order of priority (imho) :
* trim the length of the created entities to a customized number of characters. In the current version there is manual work to limit the length to something reasonable. So the entitizing process itself is very quick and spares much time, but you have to check every file afterwards for empty strings and too long entity names.
* add the extension name (or first chars of it) at the beginning of entity names (as it is common use for most of manually created entities)
* detect empty strings from the xul files and avoid creating empty useless entities
* make the .txt files editable and customizable throughout the extension interface
* fix a kind of mess that may happen when creating the doctype line in case there already is one (a "public" one, referring to FF chrome itself)

I also would add:
- definition files can be downloaded from a well known repository (similar to an update system)
- externalize starts from a given directory and its subdirectory getting all files (e.g. xml, js)
- allow to extract from JS files (maybe need a new definition file) (adding stringbundle into xul file)

any hint is welcommed

[Goofy]

definition files can be downloaded from a well known repository (similar to an update system)

If you speak of the 3 .txt files with tags to detect I am not sure that linking an online source would be a good thing. I would prefer have them more user-customizable and "inside" the extension itself.
From experience, i know the items of these files must be "adapted" sometimes according to every extension (and dev's fantasy ). To give a simple example :
I recently localized Grimholtz' big Passwordmaker extension, using my "usual" tag lists, then I realized there were tags I had never encountered before : "pickertooltiptext" so I was glad to add it on my list and not to wait for an online update.
- just my 2 eurocents

[dafi]

If you speak of the 3 .txt files with tags to detect I am not sure that linking an online source would be a good thing. I would prefer have them more user-customizable and "inside" the extension itself.
From experience, i know the items of these files must be "adapted" sometimes according to every extension (and dev's fantasy ). To give a simple example :
I recently localized Grimholtz' big Passwordmaker extension, using my "usual" tag lists, then I realized there were tags I had never encountered before : "pickertooltiptext" so I was glad to add it on my list and not to wait for an online update.
- just my 2 eurocents

You are right but I think an official taglist can be more useful.
At least (but not necessary in next release) we can combine an official list plus an user list (any duplcate can be safety removed by Externalize).

[Goofy]

Yes you are wise, let's have an "official" list (or set of lists) to give an example or a default package, just as you did for me when you released the early version + the ability to edit files for the user.

[Pedro]

...I also began a babelwiki page which is uncomplete and needing screenshots among others.

I can do it for you... let me know what kind of image you need

[dafi]

I can do it for you... let me know what kind of image you need

Consider I would change UI...

[Pedro]

Consider I would change UI...

I will wait the new UI...

[dafi]

Another brick in the wall.

Here you find the new patch.

Bugs that should be fixed

[x] trim the length of the created entities to a customized number of characters.
The algorithm used is very brutal but works fine, any hint is welcommed
[x] fix a kind of mess that may happen when creating the doctype line in case there already is one
(a "public" one, referring to FF chrome itself)
Now should work better
[x] add the extension name (or first chars of it) at the beginning of entity names
(as it is common use for most of manually created entities)
Are really useful?
[x] detect empty strings from the xul files and avoid creating empty useless entities
No more entities generated when value is empty
[x] add an extra dialog popping when a file is processed, telling "Strings from this file are
now successfully entitized, do you want to process another file ? (Y/N)" .
The dialog doesn't close, user must click on close button. I think is now more usable.
[x] Redesigned UI
Rationalized splitting in tabs
[x] Print a simple report about entities processed

[Goofy]

amazing work and improvements, dear Davide ! many thanks for that.

I have been performing a first series of tests and found everything working fine up to know.

Especially

[x] trim the length of the created entities to a customized number of characters.
The algorithm used is very brutal but works fine, any hint is welcommed

Yes it works . I noticed it added a number at the end of the entity name, I don't know if it is deliberate. see example of the increasing number list :

CODE

<!ENTITY lkwd.toolbarbutton.add.curren1 "Add current tab to a wad in your collection. CTRL+UP ARROW">
<!ENTITY lkwd.toolbarbutton.open "Open ">
<!ENTITY lkwd.toolbarbutton.open.a.wad2 "Open a wad from your collection. ALT+L">
<!ENTITY lkwd.toolbarbutton.save "Save ">
<!ENTITY lkwd.toolbarbutton.add.this.w3 "Add this wad to your collection. CTRL+S">
<!ENTITY lkwd.toolbarbutton.clear "Clear ">
<!ENTITY lkwd.toolbarbutton.close.all.4 "Close all tabs and return to home page. CTRL+ALT+Q">
<!ENTITY lkwd.toolbarbutton.options "Options  ">
<!ENTITY lkwd.menuitem.update.cache "Update Cache">
<!ENTITY lkwd.menuitem.update.your.cac5 "Update your cached account data when switching between computer systems.">
<!ENTITY lkwd.menuitem.add.url "Add URL">
<!ENTITY lkwd.menuitem.add.current.tab6 "Add current tab to a wad in your collection. CTRL+UP ARROW">
<!ENTITY lkwd.menuitem.delete.wad "Delete Wad">
<!ENTITY lkwd.menuitem.remove.current.7 "Remove current wad from your collection. ALT+DEL">
<!ENTITY lkwd.menuitem.log.in "Log In">
<!ENTITY lkwd.menuitem.log.in.to.your.8 "Log in to your account.">
<!ENTITY lkwd.menuitem.log.out "Log Out">
<!ENTITY lkwd.menuitem.log.out.of.your9 "Log out of your account.">
<!ENTITY lkwd.menuitem.report.a.bug "Report a Bug">
<!ENTITY lkwd.menuitem.file.a.bug.rep10 "File a bug report via email.">
<!ENTITY lkwd.menuitem.settings "Settings">
<!ENTITY lkwd.menuitem.set.account.in11 "Set account info and user preferences.">

[x] fix a kind of mess that may happen when creating the doctype line in case there already is one
(a "public" one, referring to FF chrome itself)
Now should work better

yes it seems ok now, though I have not yet tested the relative function. It seems to add the 2nd locale address correctly. See output example :

CODE

<!DOCTYPE dialog SYSTEM 'chrome://browser/locale/bookmarks/addBookmark.dtd'
[
<!ENTITY % bookmarkreviewerDTD SYSTEM "chrome://bookmarkreviewer/locale/addbmk.dtd" >
%bookmarkreviewerDTD;
]>

[x] add the extension name (or first chars of it) at the beginning of entity names
(as it is common use for most of manually created entities)
Are really useful?

Yes it works and it is useful when testing various extensions. When you test iand a parsing error occurs, you see generally the entity name where the prob is, but first thing to know is which extension is creating the problem.

[x] add an extra dialog popping when a file is processed, telling "Strings from this file are
now successfully entitized, do you want to process another file ? (Y/N)" .
The dialog doesn't close, user must click on close button. I think is now more usable.
[x] Redesigned UI
Rationalized splitting in tabs
[x] Print a simple report about entities processed

very good usability improvements , thanks again !

[dafi]

Yes it works . I noticed it added a number at the end of the entity name, I don't know if it is deliberate. see example of the increasing number list :

To be sure to generate an unique name an incremental value is added, this solution is known as quick and dirty .

[Goofy]

To be sure to generate an unique name an incremental value is added, this solution is known as quick and dirty .

yes I like it : quick and dirty EFFICIENT ! just fine


in the present state of the extension, you should release it on addons.moz ! I am pretty sure many devs will like it and find it time-saving (for a number of them, localizing task is just boring or ignored)

[Goofy]

Just to remember :
you added this line in the wishlist

- allow to extract from JS files (maybe need a new definition file) (adding stringbundle into xul file)

You know the stringbundle can be created on top of the .js itself, it will spare a step in the process.
See my tiny howto :
http://www.babelzill...n...=15&Itemid=


Thinking over this problem, if there are only alert ("messages") I suppose they will be easy to detect. But devs use various kinds of words to deal with messages to display (throw, dump,...) and most of the time, messages are viciously entangled with variables of all kinds...
I suspect it will be quite difficult...
Though probably "heavy" in terms of code, what with the idea of a "step by step" editing of items ?
I mean :
When the user starts the process to parse a js file, every time a new message to localize is detected, a window pops up with the original line of the .js, asking "Do you want to localize this line? (Yes/No/Cancel). Thus the user may see if the "message" is a real message to be displayed in the interface or some kind of code between quotation marks.

[dafi]

Just to remember :
you added this line in the wishlist
You know the stringbundle can be created on top of the .js itself, it will spare a step in the process.
See my tiny howto :
http://www.babelzill...n...=15&Itemid=

Oh yes, I'm working on it but I've found some problem on parser so I delayed the release.

Thinking over this problem, if there are only alert ("messages") I suppose they will be easy to detect. But devs use various kinds of words to deal with messages to display (throw, dump,...) and most of the time, messages are viciously entangled with variables of all kinds...

Another good shot Goofy
Your solution is good, JS string extraction is a less automatic task.
The steps should be:
1. detect every single and double quoted string (eg. 'Hello' or "Hello")
2. When all strings are found in file I show a summary dialog where you check which string externalize
[ ] Hello found at line 3
[x] Quick brown fox found at line 5

With a row below showing original line (useful to understand where string has been found)
3. Externalize selected strings

[Goofy]

The steps should be:
1. detect every single and double quoted string (eg. 'Hello' or "Hello")
2. When all strings are found in file I show a summary dialog where you check which string externalize
[ ] Hello found at line 3
[x] Quick brown fox found at line 5

With a row below showing original line (useful to understand where string has been found)
3. Externalize selected strings

That is exacltly what I was dreaming of!

You are really Great !
It is very pleasant for me to have someone who can make something vague and messy in my mind become rational and structured as you are doing.

[dafi]

That is exacltly what I was dreaming of!

You are really Great !
It is very pleasant for me to have someone who can make something vague and messy in my mind become rational and structured as you are doing.

Please help me to test this version ([attachmentid=1823])
that contains javascript file strings extraction.
Some bugs are present and I know their presence, like
- variable name is generated valid but not clever like for xml files
- strings on multiple lines are not handled (please ignore it )

Consider this an alpha version, I think is usable but requires a better debug tracing (I hope this night), help me to discover regression and/or new bugs

Attached Files

•  externalize_0.0.4.xpi   17.86KB   39 downloads

[Goofy]

Wow impressive stuff again.
First tests seem to give good results

My observations :
- there seem to be a useless detection of linebreakers recognized as strings, there are displayed thus : '\n'
I suggest they should not break the process, because the sentence is going on in the same string. (no need to break and begin a new string)

- the customized name at the beginning og the variable seems to duplicate itself, e.g :

CODE

var linkalertlinkalertfinding3

(name originally given : "linkalert" (once)
but it is possible I made some error while testing (?)
[2nd test : I confirm duplication of initial part of variable name)

Just as it is, and considering the user must know what he is doing whan choosing strings to process or not, it is already very efficient ! Many thanks again caro amico palermitano

[dafi]

- there seem to be a useless detection of linebreakers recognized as strings, there are displayed thus : '\n'
I suggest they should not break the process, because the sentence is going on in the same string. (no need to break and begin a new string)

I'm a bit confused, please may you make an example?

- the customized name at the beginning og the variable seems to duplicate itself, e.g :

CODE

var linkalertlinkalertfinding3

(name originally given : "linkalert" (once)
but it is possible I made some error while testing (?)
[2nd test : I confirm duplication of initial part of variable name)

Yes, confirmed bug.
I've already fixed it, I hope to upload on dafizilla a more usable version.

[Goofy]

I attach here a zipped .js file for testing purpose and you will see what I mean about linebreakers \n and other signs.
Here is a screenshot too.

By the way, the line numbers are entirely wrong

Attached Files

•  dictionaries.zip   3.26KB   32 downloads
•  jsdetection.png   6.4KB   52 downloads

[dafi]

I attach here a zipped .js file for testing purpose and you will see what I mean about linebreakers \n and other signs.
Here is a screenshot too.

Now is clear, ok I can exclude all single char strings and escape sequences.

By the way, the line numbers are entirely wrong

Oh my God this is true
Ok next build will fix also this