On Mon, Jun 22, 2009 at 00:11, Sean Flanigan
<sflaniga@xxxxxxxxxx> wrote:
On 06/20/2009 12:38 AM, Antoine Toulme wrote:
>From my experience, I think there is now room for two separate efforts:
-a nice server to hold your translations
That would be a webapp, something people will adopt to hold their translations.
That part is stable, and we may just miss some screens to manage
completely the web application from the UI. I'm thinking of defining
release trains for example.
-a framework to produce language packs
The current solution at Eclipse is satisfying,
even though we are doing more and more plumbing. For some organizations, needs may vary, the scripts need to be modified slightly (for example at Intalio, we may only want to
package
the Japanese translations at some point, for a particular customer).
Such web services would of course need to offer a stable API before calling them 1.0.
Perhaps the web services could reach 1.0, but leave the UIs as eclipse.org-only while they're changing. Or vice versa.
Yes, I'm for splitting. In terms of source code location, it doesn't necessary involve a change in the folder structure, and we already run the backend as standalone PHP scripts. So I think the split is almost there. We could just add a component in bugzilla to reflect it.
Also, people like Sean, with no PHP experience, didn't feel like they
could hack their way into producing language packs. Since then, he
provided a lot of help, but at first he was telling me he didn't feel
too confident about it.
Here's what I remember of my experience with using Babel locally. NB: this was months ago, and things may have changed.
Shortly after I discovered Babel, I set out to package the Babel langpacks as "eclipse-nls" for the Fedora project. To make a Fedora package, I need to compile from source. Since the closest thing to source is the Babel database, I was hoping to use a local Babel to generate langpacks from the nightly SQL dump. (The nightly SQL dump would thus have been included in the SRPM.)
So I checked out Babel from CVS and tried to follow the guide to set up my own server. I never got as far as trying Babel langpack generation, because all the Unicode characters were corrupted by the time they got into my database. I probably did something stupid with the mysql setup, but I didn't have time to get to the bottom of it.
In the end, I decided that the langpacks' properties files were adequate as source code (for SRPM purposes), since they are readable (with ascii2native) and editable. (Running mysql, php and Babel servers inside an RPM build also sounded tricky, at least to a Java programmer like me.) So I haven't really tried local Babel since then.
I think Denis fixed that.
I have submitted one or two minor patches for Babel since then, but I'm still completely dependent on others to test them in the context of a Babel server. I try to help Babel where I can, but I haven't been able to spend the time it would take to become really familiar with it.
What I know about langpack generation comes from my experience of generating langpacks for JBoss Tools. In the end, I decided it was less trouble to include the translations in the JBoss Tools source tree, so that they could be compiled right into the plugins, avoiding the need for separate langpacks.
I think that's just a long-winded way of saying that you shouldn't assume anything, one way or the other, from my attempts at running Babel locally. If I had just wanted to run my own translation server, and hadn't cared about importing mysql dumps, my experience might have been completely different. The same might be true if I had spent more time on the Unicode problem. In the end, I was just pulled away by other things.
I believe we should tell people that we were able to fulfill our needs
through our own php script, but that they can certainly hack their way
into the server, using Ruby, Java, or reusing our PHP script, to do
their own thing.
Does that mean the web service is pretty much there, Antoine?
No, it's not a web service. It's a PHP script you run locally. I think a build to create the fragments would need to run locally, or at least have ways to access to the DB in some way, to extract the fragments.
I had gotten started making a nice configurable PHP framework to deal with producing fragments and features, but I never got around polishing it.
So all in all, catch users with a shiny webapp, and let them come up
with patches to help with extracting fragments from the system.
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
