Eclipse committers, turn your NLS warnings on

I just came to realize that it is possible for the Eclipse compiler to track the missing NON-NLS entries, ie it can detect non-externalized strings.

Please consider opening your Eclipse, go to the preferences, then open Java>Compiler>Error/warnings and look for the option “Non-externalized strings”.

Please push that option so that it issues warnings whenever it finds a non-externalized string.

Otherwise, I’ll keep sending people to the cross-project list, or I’ll ask the AC to consider setting the non-externalized string flag as an error when compiling the Galileo RCs. I hope I won’t have to do that.

Eclipse and the lone developer

Ketan asked the Architecture Council yesterday what they should be doing for him.

He is working on a pet project, that he brought to maturity on his own. He joined Eclipse to get more support, and hopefully more coverage.

There is a price when you join Eclipse though ; you have to obey to the guidelines, use SVN or CVS, learn how to use Phoenix.

The Eclipse website is actually backed by CVS. My major concern for that practice is that everything that is checked on the website has to have a wipe-cleaned IP, as much as the IP of our code. So, for example, there is no jQuery support on the eclipse.org website. The Eclipse staff waited for six months or so for the IP of YUI to be accepted. That’s really too bad, I only needed jQuery dumb UI functions to make my website look good, I will have to learn YUI instead. Oh well.
The bottom of the issue is that the Eclipse Foundation wants to have a unified UI. I think. Well, Higgins website is quite different from the rest of the website. So I guess you could go ahead, and hack your own thing -in PHP on the Eclipse.org CVS, that is, alas.

To reply to you informally, Ketan, you are not going to get any help from Eclipse on the short term. The organization is a monolith targeted at companies. I feel your pain, and I think you should consider keeping two repositories, one on github, one on Eclipse, and do a synchronization every now and then. As long as you wrote all the code, it’s ok. If someone wants to contribute, he should clone your github repo, make a patch, and attach it to a bug. As long as you can go on like this, it should be ok.

On the long term, the IP policies are important at Eclipse, and I hope that you’ll like using Babel to internationalize your code. I also think that moving to Eclipse is giving way more coverage to your code and your project. Didn’t you have some requests from the platform committers last week on IRC ?

I think you started a nice conversation, and I’m sure the AC and yourself would have some cool ideas for Eclipse to help the lone developer. I just wish it was as easy to open an Eclipse project as it is to open a Rubyforge one.

Eclipse just had a japanese smoothie

The huge contribution made by the Blanco project, sponsored by NEC, and watched over by Mori-San, was effectively added to the Babel database today.

Thanks to everyone for your hard work on making this happen.

Babel: committer rights and updates

Hi,

I have just been voted a committer on the Babel project, and I’d like to thank the team for their warm welcome. Apparently, I fit right in as they didn’t have an Eclipse plugin developer on board just yet.

Right now, we are working on pushing for more translations of better quality, well delivered.

More translations:
I got way too much credit on this. Before, when you added a new version of a project, the previous translations were not translated. Now, they get migrated, and as a bonus, the translations from other projects that match your English string apply as well.

Better quality:
Kit made a critical improvement for the last release. It is now possible to run Eclipse with a dummy language that will show which strings are not translated correctly.

Most projects didn’t create their map files for 3.4 SR1. If you are an Eclipse project maintainer, and have changes in your translations for SR1, you might want to create the map files for this new version.

Also, map files may be missing information, or containing the test plugins that are not packaged in the final feature. I know Denis and Kit are actively working on making all those glitches go away. I think this question may be partly better addressed during delivery.

Right now, there is one global update site with a category per language. Each feature contains all the plugins of all the projects in a given language. At Intalio, we imagined a way to map the fragments to our plugins. I think p2 should be enhanced in this way to make this all work:
p2 should:
-make a list of all the plugins installed.
-install all the fragments present on the update site matching the plugins.
-create a feature on the fly matching the downloaded fragments.

What do you think of this proposal ? Is it a goal worth pursuing ?

“La cerise sur le gateau” would be to have p2 run this either inside Eclipse or headless, so we can create localized EPPs.

By the way, this begs the question of why we need features in the first place. Thoughts ?

How about a Babathon ?

Denis Roy just posted on the committers list a call for help:

[..] we need you, the Eclipse committer, to help define the PDE .map files that are used to build your project’s plugins. Once your .map files are defined, we’ll crawl through CVS, scanning for the externalized strings in the various .properties files, enabling them for translation using the web tool. The end goal is to produce language packs that everyone can download and use.[..]

To help out the work of the Babel committers, I proposed a “Babathon”:

It would be very nice to organize an event similar to a Hackathon, that would
concentrate the efforts of the community into translating as many Strings as
possible.

Please vote for this bug if you like it!

PS: Please note that projects that are hosted on Subversion cannot be used with the Babel server yet, you can follow this issue to track progress.