Community
Participate
Working Groups
As discussed in the forum, XText is not fully enabled. We need: 1) All human-readable strings to be externalized in xtext.ui. These include strings in plugin.xml, labels in java source, error messages, menus, actions, etc. 2) It would be nice if strings from the generated plugin are also externalized by default. (e.g. externalize strings from plugin.xml in the generated plugin) From the forum: (http://www.eclipse.org/forums/index.php?t=rview&goto=541694#msg_541694If) > For me to fully NL-enabled my editor, I need all human-readable strings > in the generated plugins must be externalized. These include the strings > in plugin.xml and in the java source. > > I ran the externalize string tool from Eclipse, and this is where I > found the hard-code strings: > > From the core plugin: > .. parser/antlr/MyLangParser > .. parser/antlr/MyLangAntlrTokenFileProfier > .. parser/antlr/internal/InternalMyLangParser > .. parser/antlr/internal/InternalMyLangLexer > .. services/MyLangGrammerAccess > > I think these strings are just rule names, and should not be exposed to > the user. I don't think there are any error messages produced by these > files. Although it would be nice if I can add the NON_NLS tag to these > strings, I don't think they pose a problem. > > In the UI plugin, > plugin.xml - strings for preference pages, actions contributed via > extensions, etc > ..ui/contentassit/antlr/MyLangParser > ..ui/contentassit/antlr/internal/InternalMyLangLexer > ..ui/contentassit/antlr/internal/InternalMyLangParser > ..ui/internal/MyLangActivator > > Again, I think these strings are just rule names, and should be ok. > > In the UI plugin, if I understand correctly, I can manually externalize > the strings from the pluginx.xml, and they would not be overwritten if > my plugins are regenerated? If that's the case, then I think I am ok. > > The more problematic strings are found in XText itself. > > I looked at org.eclipse.xtext.ui: > * I found that all human-readable strings like command labels, menus, > etc, are not externalized. * Secondly, I also found that strings are > just hard-coded in the Java source. e.g. ToggleSLCommentAction, the > error messages are hard-coded in the code where the error dialog is opened. > > To fully NL-enabled a plugin, I need more than just being able to > customize error messages. All human-readable strings, including UI > labels, error messages, preference pages, dialogs, etc, just be > externalized to properties files.
Hi Samantha, I've exernalized the mentioned string in ToggleSLCommentAction. Could you please list any other hard coded strings you found?
(In reply to comment #1) > Could you please list any other hard coded strings you found? There are soem progress-monitor messages hard-coded in the builder bundle.
If you run the Externalize Strings wizard, you will see a list of hard-coded strings in your plugins. The wizard works for both Java source and plugin.xml. Basically, all human-readable strings need to be externalized, including action labels, tooltips, dialog labels, error messages, etc. If you go through all the strings in the wizard, that should get your plugins NL-enabled. I have not run the wizard recently to see what other strings are not externalized. I will take another look in the next few days. Thanks. Samantha
Of course we know the Externalize Strings tool and used it to externalize the messages we consider to be read by the users of Xtext editors. Note that about 95% of our strings are not displayed to the user in the UI: They are technical or appear e.g. as exception messages (in the log only). To keep our code readable, we deliberately decided *not* to add NON-NLS messages so the tool is not too much help for us. I've externalized the strings in o.e.x.builder. If you spot more non-internationalzed messages in the UI, feel free to reopen this bug.
Thank you. I ran through the externalize string wizard with this version of the plugin - 1.0.0.v201006010502 and here's what I found: org.eclipse.xtext.ui: DirtyStateEditorSupport - found error messages not externalized DocumentBasedDirtyResource - found error messages not externalized. Not sure if these exceptions are caught and display in error dialogs. UpdateEditorImageJob - job label not externalized - if this is not a system job, this will show up in the progress monitor PreferenceConstants - EDITOR_NODE_NAME - does this show up in the preference node? XTextReconciler ToggleSLCommentAction - error message OpenXtextElementHandler - error message - not sure if exception is caught and if msg will be shown to user JavaProjectFactory - "Configure java project" - think this will show up in progress monitor XtextNewProjectWizard - message dialog title org.eclipse.xtext.builderstate MarkerUpdaterImpl - submonitor may show up in progress monitor ResourceDescriptionUpdator - submonitor strings PersistableResourceDescriptionsImpl - submonitor strings TobeBuiltConverter - submonitor strings XTextBuilder - monitor strings ProjectOpenedOrClosedListener - job title string BuildScheduler - job title string NatureAddingEditorCallBack - dialog strings
(In reply to comment #5) typo: The second plugin is this: org.eclipse.xtext.builder ... > Thank you. > > I ran through the externalize string wizard with this version of the plugin - > 1.0.0.v201006010502 and here's what I found: > > org.eclipse.xtext.ui: > DirtyStateEditorSupport - found error messages not externalized > DocumentBasedDirtyResource - found error messages not externalized. Not sure > if these exceptions are caught and display in error dialogs. > UpdateEditorImageJob - job label not externalized - if this is not a system > job, this will show up in the progress monitor > PreferenceConstants - EDITOR_NODE_NAME - does this show up in the preference > node? > XTextReconciler > ToggleSLCommentAction - error message > OpenXtextElementHandler - error message - not sure if exception is caught and > if msg will be shown to user > JavaProjectFactory - "Configure java project" - think this will show up in > progress monitor > XtextNewProjectWizard - message dialog title > > > org.eclipse.xtext.builderstate > MarkerUpdaterImpl - submonitor may show up in progress monitor > ResourceDescriptionUpdator - submonitor strings > PersistableResourceDescriptionsImpl - submonitor strings > TobeBuiltConverter - submonitor strings > XTextBuilder - monitor strings > ProjectOpenedOrClosedListener - job title string > BuildScheduler - job title string > NatureAddingEditorCallBack - dialog strings
Fixed in HEAD.
Closing bug which were set to RESOLVED before Eclipse Neon.0.
