Home » Modeling » TMF (Xtext) » How to customize XText code generation to NL-enable plugin?
| | |
| Re: How to customize XText code generation to NL-enable plugin? [message #541551 is a reply to message #540964] |
Mon, 21 June 2010 14:18   |
 Samantha Chan
Messages: 60
Registered: July 2009 |
Member |
|
|
Thanks for the response.
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.
What is the current status of NL-enablement of XText? Is it correct to assume that XText is not NL-ready? What are your plans to externalize the strings in the core XText plugins / or perhaps provide translated version of XText support?
Thanks for your help.
Samantha
|
|
|
| Re: How to customize XText code generation to NL-enable plugin? [message #541694 is a reply to message #541551] |
Tue, 22 June 2010 08:21 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Samantha,
it is correct that Xtext will override your plugin.xml.
Regarding the hardcoded strings in xtext.ui: Would you please file a
ticket and attach your findings. It's very likely that we'll fix those
ones in the upcoming service release.
Thanks,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 21.06.10 16:18, schrieb Samantha Chan:
> Thanks for the response.
>
> 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.
>
> What is the current status of NL-enablement of XText? Is it correct to
> assume that XText is not NL-ready? What are your plans to externalize
> the strings in the core XText plugins / or perhaps provide translated
> version of XText support?
>
> Thanks for your help.
> Samantha
|
|
| | |
Goto Forum:
Current Time: Thu Apr 18 05:12:14 GMT 2024
Powered by FUDForum. Page generated in 0.03044 seconds |
] 
Search
Help
Register
Login
Home
