Externalize all User Facing Strings from plugin.xml files

[azoitl]

In order to provide 4diac IDE in different languages user facing strings have to be extracted in configuration files. While we have most of these strings removed from the java files we still need to do this for the strings in plugin.xml files. These are mostly menu entries or property sheet tabs.

The tasks to be done are:

• locate all strings in plugin.xmls
• generate according plugin.property files
• configure the plugins to use these strings correctly
• Bonus: harmonize with the strings extracted from java files to reduce duplicated strings and reduce translation effort

More information on how to prepare Eclipse plugins for translation can be found in this article: https://www.eclipse.org/articles/Article-Internationalization/how2I18n.html

For tracking the plugins in questions:

• org.eclipse.fordiac.ide
• org.eclipse.fordiac.ide.ant
• org.eclipse.fordiac.ide.application
• org.eclipse.fordiac.ide.attributetypeeditor
• org.eclipse.fordiac.ide.bulkeditor
• org.eclipse.fordiac.ide.comgeneration
• org.eclipse.fordiac.ide.contracts
• org.eclipse.fordiac.ide.contractspec
• org.eclipse.fordiac.ide.contractspec.ide
• org.eclipse.fordiac.ide.contractspec.tests
• org.eclipse.fordiac.ide.contractspec.ui
• org.eclipse.fordiac.ide.contractspec.ui.tests
• org.eclipse.fordiac.ide.datatypeeditor
• org.eclipse.fordiac.ide.debug
• org.eclipse.fordiac.ide.debug.replaydebugging
• org.eclipse.fordiac.ide.debug.replaydebugging.ui
• org.eclipse.fordiac.ide.debug.st
• org.eclipse.fordiac.ide.debug.ui
• org.eclipse.fordiac.ide.debug.ui.st
• org.eclipse.fordiac.ide.deployment
• org.eclipse.fordiac.ide.deployment.bootfile
• org.eclipse.fordiac.ide.deployment.debug
• org.eclipse.fordiac.ide.deployment.debug.ui
• org.eclipse.fordiac.ide.deployment.eval
• org.eclipse.fordiac.ide.deployment.iec61499
• org.eclipse.fordiac.ide.deployment.opcua
• org.eclipse.fordiac.ide.elk
• org.eclipse.fordiac.ide.emf.compare
• org.eclipse.fordiac.ide.export
• org.eclipse.fordiac.ide.export.compare
• org.eclipse.fordiac.ide.export.forte_lua
• org.eclipse.fordiac.ide.export.forte_lua.st
• org.eclipse.fordiac.ide.export.forte_ng
• org.eclipse.fordiac.ide.export.forte_ng.st
• org.eclipse.fordiac.ide.export.ui
• org.eclipse.fordiac.ide.export.xmi
• org.eclipse.fordiac.ide.fb.interpreter
• org.eclipse.fordiac.ide.fb.interpreter.design
• org.eclipse.fordiac.ide.fb.interpreter.edit
• org.eclipse.fordiac.ide.fb.interpreter.editor
• org.eclipse.fordiac.ide.fbrtlauncher
• org.eclipse.fordiac.ide.fbtypeeditor
• org.eclipse.fordiac.ide.fbtypeeditor.doc
• org.eclipse.fordiac.ide.fbtypeeditor.ecc
• org.eclipse.fordiac.ide.fbtypeeditor.network
• org.eclipse.fordiac.ide.fbtypeeditor.servicesequence
• org.eclipse.fordiac.ide.fbtypeeditor.st
• org.eclipse.fordiac.ide.fmu
• org.eclipse.fordiac.ide.fortelauncher
• org.eclipse.fordiac.ide.gef
• org.eclipse.fordiac.ide.gitlab
• org.eclipse.fordiac.ide.globalconstantseditor
• org.eclipse.fordiac.ide.globalconstantseditor.ide
• org.eclipse.fordiac.ide.globalconstantseditor.model
• org.eclipse.fordiac.ide.globalconstantseditor.tests
• org.eclipse.fordiac.ide.globalconstantseditor.ui
• org.eclipse.fordiac.ide.globalconstantseditor.ui.tests
• org.eclipse.fordiac.ide.hierarchymanager.build
• org.eclipse.fordiac.ide.hierarchymanager.model
• org.eclipse.fordiac.ide.hierarchymanager.model.edit
• org.eclipse.fordiac.ide.hierarchymanager.ui
• org.eclipse.fordiac.ide.images
• org.eclipse.fordiac.ide.library
• org.eclipse.fordiac.ide.library.model
• org.eclipse.fordiac.ide.library.ui
• org.eclipse.fordiac.ide.model
• org.eclipse.fordiac.ide.model.commands
• org.eclipse.fordiac.ide.model.edit
• org.eclipse.fordiac.ide.model.eval
• org.eclipse.fordiac.ide.model.eval.st
• org.eclipse.fordiac.ide.model.search
• org.eclipse.fordiac.ide.model.search.st
• org.eclipse.fordiac.ide.model.ui
• org.eclipse.fordiac.ide.product
• org.eclipse.fordiac.ide.resourceediting
• org.eclipse.fordiac.ide.runtime
• org.eclipse.fordiac.ide.structuredtext.mwe
• org.eclipse.fordiac.ide.structuredtextalgorithm
• org.eclipse.fordiac.ide.structuredtextalgorithm.ide
• org.eclipse.fordiac.ide.structuredtextalgorithm.model
• org.eclipse.fordiac.ide.structuredtextalgorithm.tests
• org.eclipse.fordiac.ide.structuredtextalgorithm.ui
• org.eclipse.fordiac.ide.structuredtextcore
• org.eclipse.fordiac.ide.structuredtextcore.ide
• org.eclipse.fordiac.ide.structuredtextcore.model
• org.eclipse.fordiac.ide.structuredtextcore.ui
• org.eclipse.fordiac.ide.structuredtextfunctioneditor
• org.eclipse.fordiac.ide.structuredtextfunctioneditor.ide
• org.eclipse.fordiac.ide.structuredtextfunctioneditor.model
• org.eclipse.fordiac.ide.structuredtextfunctioneditor.tests
• org.eclipse.fordiac.ide.structuredtextfunctioneditor.ui
• org.eclipse.fordiac.ide.structuredtextfunctioneditor.ui.tests
• org.eclipse.fordiac.ide.subapptypeeditor
• org.eclipse.fordiac.ide.systemconfiguration
• org.eclipse.fordiac.ide.systemconfiguration.segment
• org.eclipse.fordiac.ide.systemmanagement
• org.eclipse.fordiac.ide.systemmanagement.ui
• org.eclipse.fordiac.ide.typeeditor
• org.eclipse.fordiac.ide.typemanagement
• org.eclipse.fordiac.ide.ui
• org.eclipse.fordiac.ide.ui.errormessages
• org.eclipse.fordiac.ide.util
• org.eclipse.fordiac.ide.validation

[sshekhar-04]

Hi @azoitl ,

I’ve begun working on externalizing the strings in the plugin.xml files. I've successfully set up the org.eclipse.fordiac.ide.ui plugin with a plugin.properties file and configured the MANIFEST.MF for localization as a test.

To keep the review process manageable, would you prefer that I submit the changes in small batches (i.e, 2–3 plugins per PR) or should I wait and submit a single larger PR for all plugins once completed?

I am also making sure to harmonize the new keys with any existing strings in the plugin.properties files to avoid duplicates.

Looking forward to your preference!

[azoitl]

@sshekhar-04 thx that you are addressing this issue. I'm a big fan of small PRs. I would say 1 plugin per PR would already be an upper bound. For large plugins like application even just a subset of the strings could be feasible.

[sshekhar-04]

@azoitl thanks for the feedback! That makes perfect sense. I will stick to the '1 plugin per PR' rule to keep things clean. I've just submitted my first PR for the "ui" plugin for your review. Once that looks good, I'll move on to "fbtypeeditor" and "application" next. Thanks again!

[sshekhar-04]

Hi @azoitl , since this issue is now closed with the merge of the "ui" plugin PR, would you like me to continue with the other plugins (like application and fbtypeeditor)? I can open a new tracking issue for the remaining plugins or simply continue submitting PRs one by one as we discussed.

[azoitl]

@sshekhar-04 I didn't notice that this issue was closed. You used Fixes #2026 in your PR. When I merged your PR Github automatically closed it. I re-opend it as I wanted this issue here as the issue for tracking all work on this issue. Please refere to this issue in your future PRs but do not use fixes or closed that lets Github autoclose this issue.

[sshekhar-04]

Understood, @azoitl ! My apologies for the auto-close—I'll use 'Refers to' or 'Part of' in the future PRs to keep this tracking issue open. I'm starting on the "fbtypeeditor" plugin next.

[azoitl]

@sshekhar-04 I also just noticed that you pushed your PR to the release branch. I missed that when I merged your PR. Please note that we do our developments on the develop branch. Please use that for any future PRs from you.

[sshekhar-04]

Thank you for the correction, @azoitl. My apologies for the branch mix-up as well; I have synchronized my local environment with the develop branch and will ensure all future PRs target develop instead of release.

I'll also use 'Part of #2026' to prevent any more accidental auto-closures. Starting on the next plugin now!