Community
Participate
Working Groups
We are now adding the annotation and overview rulers into the SourceEditor component of Firefox, as part of our work to allow users to debug JavaScript. The tooltips that show when annotations are hovered with the mouse include strings that cannot be localized. One of the strings is found in the TextView code, in ruler.js. More specifically, the OverviewRuler has a "Line: " string that tells users in a tool tip the line number their mouse is pointing at. We would like to enable our code to show tooltips when the user hovers annotations in the overview ruler. We cannot do this without having all displayed strings localizable. Can someone please look into this and make a mechanism that allows us to provide our strings for the Orion TextView code? Please note that the work are are doing is only with the TextView component - we haven't added editor.js/editorFeatures.js yet. Thank you!
This suggests to me that our localization strategy in the editor couldn't rely, for example, on dojo's localization strategy. Something to consider as we move forward, whether what we do in the editor will be the same as elsewhere.
I believe these are the localizable strings in "textview" (Commit 2556c1ce7208b365ff862811d83cdd7c591b483a): tooltip.js:204 -> Multiple annotations: ruler.js:557 -> Line: textStyler.js:966 -> "Matching Bracket" textStyler.js:975 -> "Current Bracket" These are the ones in "editor": asyncStyler.js:165 -> "Syntax error." editor.js:426 -> "Current Line" editor.js:622 -> Line/Col editorFeatures.js:114 -> "Incremental find: " editorFeatures.js:124 -> "Incremental find: " and " (not found)" .... more
Fixed: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=ea8fda42a89507807a57cc87a185a408fa9e3d43 http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=451ef35657213f846824e40f7a4aee462aa4cf02 We used the i18n support from requirejs: http://requirejs.org/docs/api.html#i18n One missing functionality we had to do ourselves (since we don't use dojo) was http://dojotoolkit.org/reference-guide/dojo/replace.html This is necessary for cases like this: http://www.ibm.com/developerworks/web/library/wa-dojo/ Keeping this problem open till we verify how to integrate this solution with almond. Mihai, are you still using global.js ?
(In reply to comment #3) > Fixed: > > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=ea8fda42a89507807a57cc87a185a408fa9e3d43 > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=451ef35657213f846824e40f7a4aee462aa4cf02 > > We used the i18n support from requirejs: > http://requirejs.org/docs/api.html#i18n > > One missing functionality we had to do ourselves (since we don't use dojo) was > http://dojotoolkit.org/reference-guide/dojo/replace.html > This is necessary for cases like this: > http://www.ibm.com/developerworks/web/library/wa-dojo/ Thanks! Much appreciated! > Keeping this problem open till we verify how to integrate this solution with > almond. > > Mihai, are you still using global.js ? Yes, I still do. The current Orion update I am preparing for Firefox still uses global.js - I am focusing on polish and debugger-needed features (breakpoints). We have a bug open about switching away from global.js and it seems the next integration will probably have to do this - due to the i18n work. Thanks again!
I was able to see the i18n support working with almond. First, there is a small bug in almond that needs fixing before anything works. https://github.com/jrburke/almond/issues/13 Secondly, without dynamic loading all the NLS files need to be included either on the html file or during compile time.
Example how to compile an application using text view and almond: $ node r-edge.js -o baseUrl=../.. name=examples/textview/almond include=examples/textview/orionformatter.js,orion/textview/nls/pt-br/messages.js,o rion/textview/nls/fr-fr/messages.js out=orionformatterbuilt.js optimize=none We could fix global.js to handle i18n files (because webEditintPluging still uses it) but it would have all the same limitation.
Created attachment 210611 [details] global.js with i18n support This is an attempt to add i18n support to global.js. It seems to works, but we are not going to release this because I believe people should be using either almond or requireJS instead of global.js.
(In reply to comment #7) > Created attachment 210611 [details] > global.js with i18n support > > This is an attempt to add i18n support to global.js. It seems to works, but we > are not going to release this because I believe people should be using either > almond or requireJS instead of global.js. Note that the webEditingPlugin.html plugin will have to deal with this when the content assist files (htmlContentAssist.js, cssContentAssist.js and jsContentAssist.js) are properly NLSed.
> > First, there is a small bug in almond that needs fixing before anything works. > https://github.com/jrburke/almond/issues/13 this bug is fixed in newer versions of i18n.
Marking as Fixed since the basic files are NLSed.
