Community
Participate
Working Groups
We should go through tooling and externalize all strings for internationalization.
Finished. Please see: https://github.com/MilesParker/Virgo-Tooling/commit/a317731397de177c97d08f3db396bcbc5912e424 Leo, if this looks ok, please commit. 1) I wrote all of this code. 2) I have authorization from my employer to submit it.
Hi Miles. This is a really big contribution, so I want to be sure to take care it's done right. Here are a few comments: 1) All of the new Messages.java files have a proprietary license header attributing the code to Metascape. If that was unintentional, the headers should be updated to something Eclipse friendly, acknowledging Tasktop as the contributing organization. The Virgo project has some guidelines for how this should be done at http://wiki.eclipse.org/Virgo/Committers/Coding#Code_Formatting_and_Templates 2) There are a few places where constants are being externalized where they shouldn't be. For example the EDITOR_ID strings in ParEditor and ParManifestEditor 3) Some of the message keys aren't descriptive, which will make it difficult for others to later add an internationalization. I see a lot of keys ending in numbers in org.eclipse.virgo.ide.ui/src/org/eclipse/virgo/ide/ui/editors/Messages.java and in org.eclipse.virgo.ide.ui/src/org/eclipse/virgo/ide/ui/wizards/Messages.java 4) Some of the externalized strings haven't been given values. For example in org.eclipse.virgo.ide.ui/src/org/eclipse/virgo/ide/ui/editors/messages.properties there are quite a few entries with no values. 5) I'm having a hard time figuring out what's changed in 3 or 4 files, because git is showing almost the entire file has changed. AbstractImportSection.java, BundleExecutionEnvironmentSection.java, and BundleLibrarySection.java together account for over 3000 lines changed. Maybe it's just an errant reformatting? You shouldn't feel that you're blocked on other things while you're trying to get externalization through. While it's great to have our String externalized, it is a lot of work and it's lower priority than some of the other items on our list.
OK.. 1) Argh! That was completely an oversight; I forgot that my default code formatting had that header in it. It's totally wrong obviously. I'm likely going to try simply backing out the current change and resubmitting. 2 & 3 & 4) I meant to say that these were really rough, but really the whole thing is pretty rough. That's what you get for using automated tools. 5) I'm not sure what's up with the formatting. In any case, we'll obviously hold off on submission until I get those fixes squared away. I'd just dump the whole submission but this was a fair amount of work. I was anxious to get the externalization out of the way as I was thinking it would help with isolating the other tokens.
OK, let's try again: https://github.com/MilesParker/Virgo-Tooling/commit/5137f732607007f6ddeca1cd708effcc66c7a0cc 1) Shouldn't even show up in the history now. 2 & 3) Were actually the same cause. I think I've fixed all of those but let me know if not. 4) Were spurios and I've removed. 5) I'm not sure what happened with those files. I couldn't see any difference. The eclipse editor also thought they were different. I think it might have been a line-ending issue. Anyway, those should be gone now.
This contribution will need a CQ unless we defer it until Miles is a committer. Miles: It seems a shame to get the IP team involved unnecessarily. So please can you identify some small fixes to gain your committership fast? It's fine to develop larger changes in parallel providing we can hold these off in github.
Can this issue be closed. Miles?
Unfortnatly, no. I'll look and see if all of the git work I did before becoming a committer is still relvant, but so much has changed since I spent the time on this. I think internationalization support will have to wait.
Let's leave this one open. Won't be in release but it needs to be tackled at some point.
