Community
Participate
Working Groups
Created attachment 91768 [details] screen capture Source folder name, for example "src", should not be in NL jar. org.eclipse.ui.ide.nl_<locale>.jar is one example. Eclipse cannot find the translations if we have the source folder there.
Created attachment 92074 [details] Patch to remove source folder This is really bad, because a lot -- if not most -- of the translations are lost with the source folder being there, right? Here's a patch to remove the source folder. Here's a visual model of how it works org.eclipse.ltk.core.refactoring/src/org/eclipse/ltk/internal/core/refactoring/RefactoringCoreMessages.properties ~~~~~~~~~~~~ XXXX ~~~~~~~~~~~ == MATCH `-----------------------------------^ org.eclipse.platform/src-intro/org/eclipse/platform/internal/messages.properties ~~~~~~~~~~~~ XXXXXXXXXX ~~~~~~~~~~~ == MATCH `-------------------------------^ org.eclipse.ant.ui/Ant_Tools_Support/org/eclipse/ant/internal/ui/preferences/AntPreferencesMessages.properties ~~~~~~~~~~~~ XXXXXXXXXXXXXXXXXX ~~~~~~~~~~~ == MATCH `-----------------------------------^ org.eclipse.sdk.tests/plugin.properties == NO MATCH The regexp itself works on the dozen files I have tested, but I need to commit this to the staging area to see if it works in the context of the language pack.
(In reply to comment #1) > to see if it works in the context of the language pack. I have no idea what that means.
If we apply a similar regexp patch to the English source files (but we may have to re-import some of the translations again), we may simplify the file paths and solve a few problems at once (like the word wrap problem caused by the space in source folder name - bug 219091, and the NL pack generation problem reported by this bug).
That's a good idea, but we won't need to reimport -- the file path and name are not the primary key, so I can just run a script to pass the file names through the regexp, then apply the regexp patch to the maps processor. I'm rebuilding the language packs to test the regexp. If it works, then I'll do the above.
(In reply to comment #4) > I'm rebuilding the language packs to test the regexp. If it works, then I'll > do the above. Actually, after thinking this through for about 74 seconds I think it's best to filter/fix the file name while generating the language pack. Most projects have different naming conventions that may require different fixes. It's easier (but less efficient) to fix those names on the output, rather than fix them manually in the DB and on the input.
>It's easier (but less efficient) to fix those names on the output, rather than fix them manually in the DB and on the input. Okay, let's try that first.
I've rebuilt the language packs with the fix and put them in our staging area: http://build.eclipse.org/technology/babel/test-updates/ I haven't tested them yet, but if someone wants to beat me to it, feel free.
Created attachment 92185 [details] screen captures It looks much better now!!! Many strings in English a few days ago are now displaying as translated! Great job! Thanks! We just have a few problems with extra slashes before some colons and equal signs, and some problems with new line characters. They could be messed up during the import. I will narrow that down and open separate bugs if needed. But, we should resolve this bug.
I've put the generate1.php code in the live tree, so the packs should be ok from tomorrow on. I feel that manipulating the file names while generating the packs, however less efficient, is more robust and flexible than trying to mess with the raw file name as pulled from CVS. Closing as fixed.
Released > R_0_200804081317
Verified
closing
*** Bug 235132 has been marked as a duplicate of this bug. ***
Reopening ... where birt has files like this, where the source folder is correctly removed: source/org.eclipse.birt.report.data.oda.jdbc.dbprofile.sampledb/plugin.properties webtools has files like this, where only the first directory is removed: common/docs/org.eclipse.wst.validation.doc.isv/plugin.properties I need to re-examine my regexp in generate1.php (as soon as I can remember how it works): $pattern = '/^([a-zA-Z0-9_-]+)\.([a-zA-Z0-9_-]+)\.(.*)\/(.*)\/(\1)\/(\2)\/(.*)\.properties$/i'; $replace = '${1}.${2}.${3}/${5}/${6}/${7}.properties';
I added one regex and modified the existing one. The new code successfully cleans these file names (characters above X removed): org.eclipse.jpa/components/jpa/plugins/org.eclipse.jpt.eclipselink.ui/property_files/eclipselink_ui.properties XXXXXXXXXXXXXXXXXXXXXXX org.eclipse.equinox/bundles/bundles/org.eclipse.equinox.http.jetty6/plugin.properties XXXXXXXXXXXXXXXX source/org.eclipse.birt.report.data.oda.jdbc.dbprofile.sampledb/plugin.properties XXXXXXX servertools/docs/org.eclipse.server.doc.isv/plugin.properties XXXXXXXXXXXXXXXXX org.eclipse.pde.api.tools/src_ant/src1/src2/src3/src4/org/eclipse/pde/api/tools/internal/tasks/messages.properties XXXXXXXXXXXXXXXXXXXXXXXXXXXX org.eclipse.pde.api.tools/src_ant/org/eclipse/pde/api/tools/internal/tasks/messages.properties XXXXXXXX org.eclipse.pde.p2.ui/plugin.properties (nothing removed) I've committed this to staging and will run a test build.
> I've committed this to staging and will run a test build. Here's an update site that contains a language pack with this fix: http://build.eclipse.org/technology/babel/denis-updates/ganymede/ Kit, can you test to see if all is well?
I've verified that the WTP language packs are built correctly now! I will take a deeper look at language packs for other projects (like BIRT) to make sure everything is built okay. So far, it's very promising. Thanks!
Didn't mean to be anonymous. Last comment was from me :-) Kit
This fix is now live.
*** Bug 237288 has been marked as a duplicate of this bug. ***
