[JBoss JIRA] (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-4044?page=com.atlassian.jira.plugin... ]
Nick Boldt closed JBIDE-4044.
-----------------------------
Fix Version/s: 3.2.3.Final
(was: 3.3.x)
Resolution: Out of Date
Subtasks are done and this hasn't been looked at since 2011, so closing Out of Date.
> Review unused strings as reported by "Find Broken Externalized Strings"
> -----------------------------------------------------------------------
>
> Key: JBIDE-4044
> URL: https://issues.jboss.org/browse/JBIDE-4044
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: cleanup
> Affects Versions: 3.1.0.M1
> Reporter: Sean Flanigan
> Assignee: Sean Flanigan
> Labels: i18n
> Fix For: 3.2.3.Final
>
> Attachments: unused_messages_in_jbosstools.zip
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I've run UCDetector [1] against the codebase, and it has found 294
> fields in *Messages classes which have 0 references. I've attached a
> list (views well in oocalc). I'd like to remove them, along with their
> corresponding resourcebundle properties, to reduce the number of
> translatable strings before localisation begins.
> I think it should be safe to remove these fields, since any direct usage will be caught by the compiler as soon as we try to remove it (and wouldn't have been listed by UCDetector anyway, unless it is completely broken), and it would be extremely unlikely for anyone to access a Messages field by reflection.
> If you want to run UCDetector yourself, select one or more plugin projects (not features, not non-Java projects), select UCDetector/Detect unnecessary code, and wait. I recommend configuring Eclipse's Problems view to show problems of type "UCDetector Marker (References)" whose description contains 'Field "'. The relevant problems are of the form 'Field SomethingMessages.SOME_KEY" has 0 references'.
> [1] http://ucdetector.sourceforge.net/
> EDIT:
> Forget about UCDetector for this! It looks like Eclipse's built in feature "Find Broken Externalized Strings" is much better for this specific case. Not to mention a lot faster!
> Looking through the results, I'm getting an idea what Max meant about false positives, because some properties files are used both through a Messages accessor class and directly via ResourceBundle, sometimes by concatenating prefixes to construct the keys. Like Eclipse, I assumed that wouldn't happen to a bundle which has a Messages accessor class, but I was obviously wrong.
> I would suggest switching to "Find Broken Externalized Strings", because (unlike UCDetector) it can handle properties files accessed through old-style Messages classes with getString() methods.
> You can run Source/Find Broken Externalized Strings against a package, project, or group of projects. I've cleaned up as well as I can, and reviewed the supposedly "undefined keys". Here is the resulting list of resourcebundles with at least 20 suspected unused keys:
> archives:
> ArchivesUIMessages.properties - org.jboss.ide.eclipse.archives.ui/src/main/org/jboss/ide/eclipse/archives/ui (43 matches)
> (accessor class org.jboss.ide.eclipse.archives.ui.ArchivesUIMessages)
> common:
> JavaUIMessages.properties - org.jboss.tools.common.model.ui/src/org/jboss/tools/common/model/ui/util (69 matches)
> XmlEditorMessages.properties - org.jboss.tools.common.text.xml/src/org/jboss/tools/common/text/xml/ui (49 matches)
> hibernate:
> HibernateConsoleMessages.properties - org.hibernate.eclipse.console/src/org/hibernate/eclipse/console (60 matches)
> (accessor class org.hibernate.eclipse.console.HibernateConsoleMessages)
> jst:
> messages.properties - org.jboss.tools.jst.web/src/org/jboss/tools/jst/web/messages (29 matches)
> (accessor class org.jboss.tools.jst.web.messages.xpl.WebUIMessages)
> TilesEditorMessages.properties - org.jboss.tools.jst.web.tiles.ui/src/org/jboss/tools/jst/web/tiles/ui/editor (74 matches)
> vpe:
> messages.properties - org.jboss.tools.vpe/src/org/jboss/tools/vpe/messages (23 matches)
> (accessor class org.jboss.tools.vpe.messages.VpeUIMessages)
> To get the exact list of affected strings, you will need to run Source/Find Broken Externalized Strings against the relevant package (or your whole workspace if you like). I'm sure a lot of these are false positives, but even so, it would be helpful to have explanatory comments in the affected properties files. Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBIDE-3557) Externalise English strings (move them from source code into .properties)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-3557?page=com.atlassian.jira.plugin... ]
Nick Boldt closed JBIDE-3557.
-----------------------------
Fix Version/s: 3.2.3.Final
(was: 3.3.x)
Resolution: Out of Date
Closing Out of Date as this hasn't been looked at since 2009.
> Externalise English strings (move them from source code into .properties)
> -------------------------------------------------------------------------
>
> Key: JBIDE-3557
> URL: https://issues.jboss.org/browse/JBIDE-3557
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cleanup
> Reporter: Sean Flanigan
> Assignee: Sean Flanigan
> Labels: i18n
> Fix For: 3.2.3.Final
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> Much of the English text in JBoss Tools is already externalised into .properties files, but my pseudolocalisation testing [1] shows that there is still some hard-coded English text, particularly in files like plugin.xml and feature.xml, but also in parts of the Java source.
> Any such English text needs to be moved out of the source code into .properties files, and replaced by ResourceBundle lookups.
> - In the case of plugin.xml or Java source, Eclipse's "Externalize Strings" wizard can help. In most cases, if a plugin already has a ResourceBundle, for instance org.jboss.tools.{plugin}.Messages, it is best to reuse this bundle, rather than creating another one for each package in the bundle. (More bundles create more work for translators.)
> - In the case of feature.xml, there doesn't seem to be an Eclipse wizard, so externalisation has to be done by hand.
> [1] Running JBoss Tools together with Eclipse's Babel langpacks, plus the JBoss Tools langpacks. http://www.jboss.org/community/docs/DOC-13256
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBDS-726) Installer should deploy Babel langpacks for Eclipse
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-726?page=com.atlassian.jira.plugin.s... ]
Nick Boldt closed JBDS-726.
---------------------------
Fix Version/s: 4.1.4.GA
(was: LATER)
Resolution: Out of Date
This issue has gone untended since Jun 2009, so I'm closing it as Out of Date. If you disagree, please open a new issue re: translations / langpacks / Babel.
> Installer should deploy Babel langpacks for Eclipse
> ---------------------------------------------------
>
> Key: JBDS-726
> URL: https://issues.jboss.org/browse/JBDS-726
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 2.1.0
> Reporter: Sean Flanigan
> Labels: L10n
> Fix For: 4.1.4.GA
>
>
> For Developer Studio to be fully translated, we need to package the Babel langpacks for Galileo [1] in our target languages [2]. These langpacks provide translations for Eclipse and related eclipse.org projects (TPTP, datatools, etc). Translations are always being updated, so we will need to be able to update the langpacks without too much mucking around.
> NB: This issue is separate from the question of translating the installer's own English text.
> To install the langpacks, we just need to extract them all under jbdevstudio/eclipse/dropins (or perhaps dropins/babel for neatness).
> Any guidance on how to approach this? eg, the storage of these langpack downloads, repackage as one big zip (better compression?) or keep the many smaller zips, whether we need a script (sh, Ant?) to download the required langpacks automatically, that sort of thing.
> [1] http://download.eclipse.org/technology/babel/babel_language_packs/
> [2] de, es, fr, ja, pt_BR, zh
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBIDE-4130) Translation of JBoss Tools (L10n)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-4130?page=com.atlassian.jira.plugin... ]
Nick Boldt closed JBIDE-4130.
-----------------------------
Fix Version/s: 3.2.3.Final
(was: LATER)
Resolution: Out of Date
This issue has gone untended since 2011 with no resources allocated, so I'm closing it as Out of Date. If you disagree, please open a new issue re: translations / langpacks / Babel. Also please provide some resources. :)
> Translation of JBoss Tools (L10n)
> ---------------------------------
>
> Key: JBIDE-4130
> URL: https://issues.jboss.org/browse/JBIDE-4130
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: z - Legacy - integration
> Reporter: Sean Flanigan
> Priority: Critical
> Labels: integration
> Fix For: 3.2.3.Final
>
>
> This feature request is for the overall localization of JBoss Tools. To start with, we need at least the following locales/languages:
> - Japanese (ja_JA)
> - Simplified Chinese (zh_CN)
> - Brazilian Portuguese (pt_BR)
> - Spanish (es_ES)
> - French (fr_FR)
> - German (de_DE)
> We can add sub-tasks and/or dependencies as appropriate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months