Community
Participate
Working Groups
Build Identifier: 20100617-1415 There are no Language-Packs for helios for tools.gef. The latest emf-strings are for emf 3.5 It would be great if someone could update this to 3.6 so we could do more translations on this. Reproducible: Always
*** This bug has been marked as a duplicate of bug 320625 ***
The following project/versions have not defined a map file for Helios, and are therefore not translatable (and there are no Helios language packs): modeling.emf 2.6.0 tools.gef 3.6 rt.equinox 3.6 modeling.mdt 3.1.0 Am I missing any others?
So if this is for the projects themselves to fix shouldn't we file bugs at the respective projects GEF,EMF,MDT and Equinox? For GMF there were things to do for the babel team and for the gmf team, whereby I didn't completely understand the process: https://bugs.eclipse.org/bugs/show_bug.cgi?id=318974
> So if this is for the projects themselves to fix shouldn't we file bugs at the > respective projects GEF,EMF,MDT and Equinox? Yes, I meant to do that bug got sidetracked. Johannes do you want to file the bugs, and mark them as blocking this one?
(In reply to comment #4) > Yes, I meant to do that bug got sidetracked. Johannes do you want to file the > bugs, and mark them as blocking this one? Yes, I just did this. Thanks for the hint.
Thanks for your help!
Well, these bugs don't seem to get addressed by their projects. If you could provide a simple step-by-step-tutorial on how to create this mapping file, I think it would be easier to convince the projects to do this steps. Especially for MDT they don't know howto do this apparently :-(
Just adding Kit Lo to this. He helped providing latest babel for GMF. Maybe it would be best if we could have some short instructions on what to do to syncup for latest Version in Babel? This is what Kit answered when solving the problem for GMF: I entered the gmf.notation & gmf.runtime map files, ran the syncup script to pull in existing translations. Language packs are built properly (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=318974)
I'm working on this. Looks like both GEF & EMF do not have map files tagged for the Helios release. I have to contact the project leads to find out why. MDT has many sub-projects. Johannes, do you want to see the strings for OCL, ULM2 or other projects?
Thank you Kit for your helping! For previous versions there was only one MDT Languagepack (org.eclipse.babel.nls_modeling.emf_de_3.5.0.v20100821074508), wasn't there? But if it depends on the sub-project, we'd most urgently need the ocl and validation-localizations for our tool.
I contacted the committers of the projects and figured out the map files for the projects. Map files for the following projects for the Helios release train have been defined in Babel: modeling.emf.validation modeling.mdt.ocl tools.gef Note: the map files for the following projects were defined recently: rt.equinox rt.equinox.p2 I ran the syncup script to pull in existing translations. Language packs are built properly. See http://build.eclipse.org/technology/babel/babel_language_packs/I20100904-0400/helios.php
Hi Kit, thanks for your work. However, the Map-Files and the language-packs for modeling.emf itself are still missing in version 2.6.0. Could you create (or help creating) this mapfile too? Until then, I think we should leave this bug in status open, shouldn't we? Would be great, best regards Johannes
Contributors are interested in translating modeling.emf R2_6_0. I cannot find the map file with the R2_6_0 tag. Can someone from the EMF project provide that so the Babel project can extract all the files and make them available for the community to translate?
I haven't even the tiniest clue where you are looking and what you're hoping to find there. Assume I know nothing and that I'll need detailed information. I'll assume that finding R2_6_maintenance as the tag for the maintenance 2.6 maintenance stream will suit your needs. It includes any fixes such as those for 2.6.1 SR1.
We are looking for the CVS map file to check out all the source files for modeling.emf R2_6_0 so that we can extract all the Java properties files and provide to the community for translation. Found the follwoing URL. Not sure if that's right. Can someone confirm? http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf/releng/org.eclipse.emf.releng.athena/maps/emf.map?view=co&root=Modeling_Project&pathrev=R2_6_0
The fixes are available in a published build.
Here I wonder what the root cause and the fix was. Was it caused by using Buckminster for building now instead of Nick's modeling build? If so, other Buckminster builds (like CDO's) might also be affected. Where did you get your map file from? Can a Buckminster build produce this map file? Even if it could I doubt that Hudson could check it in.
(In reply to comment #17) > Here I wonder what the root cause and the fix was. > I think Ed mistakenly marked this bug as resolved. The "root cause" is that Buckminster does not use map files to produce a build, so the map files that used to be consumed/updated by the "old" build aren't with the "new" Buckminster build. > Was it caused by using Buckminster for building now instead of Nick's modeling > build? If so, other Buckminster builds (like CDO's) might also be affected. Yes. > Where did you get your map file from? Can a Buckminster build produce this map > file? Even if it could I doubt that Hudson could check it in. No, Buckminster neither consumes nor produces a map file.
It sounds like this affects all Buckminster builds. I think folks relying on map files better find a different way to achieve their goal because I'm not in a position to produce them anymore.
(In reply to comment #18) > > Where did you get your map file from? Can a Buckminster build produce this map > > file? Even if it could I doubt that Hudson could check it in. > No, Buckminster neither consumes nor produces a map file. So, there's no more tagging before/after builds, and "releasing" those tags into a map? I was under the impression that Bucky was a wrapper over PDE so it should still support this notion (as Athena does). Only reason you shouldn't be able to produce/consume map files is if you switch to Tycho/Maven. Anyway, if your issue is a Bucky one, you're SOL from my end. I know very little about Buckminster and while I do talk about it as a viable alternative to Athena, PDE, Tycho, or Maven, I have never claimed to *support* it personally. Reassigning to Kenn since he's at least a Cloudsmith guy and therefore prolly knows more about Bucky than I do. Cheers!
(In reply to comment #20) > So, there's no more tagging before/after builds, and "releasing" those tags > into a map? That's correct. I mean, it's not required/supported by Bucksminster, but nothing is stopping someone from still doing it for the sake of maintaining a map. But good luck getting Ed to do it. ;) > I was under the impression that Bucky was a wrapper over PDE so it > should still support this notion (as Athena does). Buckminster uses only a subset of PDE. > Reassigning to Kenn since he's at least a Cloudsmith guy and therefore prolly > knows more about Bucky than I do. Cheers! I know marginally more, but I unfortunately have no way of providing an automated solution at this time.
(In reply to comment #21) > > Reassigning to Kenn since he's at least a Cloudsmith guy and therefore prolly > > knows more about Bucky than I do. Cheers! > > I know marginally more, but I unfortunately have no way of providing an > automated solution at this time. Most build systems, Buckminster included, does not use map-files (they have no use for it). I fail to see how that makes those systems the culprit. The real problem IMHO, is that other builds rely on EMF to use a particular type of build. That's not a reasonable requirement and that's the problem that needs to be fixed.
(In reply to comment #22) > [...] The real > problem IMHO, is that other builds rely on EMF to use a particular type of > build. That's not a reasonable requirement and that's the problem that needs to > be fixed. I fully agree. Although in this particular case (see bug description) it seems to be an Eclipse-made problem because it's this translation management system (forgot its name) that seems to require these map files. Seems that either they add support for other build types or we provide the map files or we live without user translations ;-(
I just noticed that Babel can now read p2 repositories in addition to map files: http://babel.eclipse.org/babel/map_files.php I registered our CDO milestone composite repository and Babel says it will look at it over the night. Let's see how that works...
CDO language packs were produced properly in Babel Language Pack R0.9.0. See http://download.eclipse.org/technology/babel/babel_language_packs/R0.9.0/indigo/indigo.php
Closing all fixed releng bugs.
