RE: [babel-dev] Re: Home for translation tools?

["Stefan Mücke" <s.muecke@xxxxxxxxx>]

Pascal,

indeed, you have a lot of code in your implementation and most of it is missing in my implementation. So, I think it would be good to keep most of your "core" code but to drop the UI, because the UI doesn't scale for a larger number of bundles. What I meant by editing "all bundles at the same time" was actually "all bundle groups (or families) at the same time."  The big advantage of having a table is that you can read all bundle entries immdiately. You don't need to click on a key. You can easily find what you are looking for. Just give my implementation a try. You only need to enter a key (or part of it) or any term that occurs in a translation, and you will immediately get all matching entries. For me, this was one of the most important features in the UI. The problem I had was to make the translation consistent across my whole application (and this needed to be done in Russian :-). Some translations needed to be changed multiple times until an appropriate term was found. Without my table view there was no possibility to look up the entries. You could not even use the search, because all strings were escaped in the bundle files.

Just have a look at my editor. I am sure you will be pleased. Then, perhaps, you might get an idea how to combine your "core" features with that UI. My (data) model is very simple and could easily be replaced, enhanced, or merged with a different implementation.

Note: The editor can be opened via menu: Edit > Open Localization Editor.

The main "problem" with my implementation is that it currently uses an in-memory model. This doesn't scale for *very* large localizations, at least if all bundle languages are loaded at the same time (Eclipse SDK + NL1 + NL2 currently consumes about 90 MB). One solution could be to load only those languages that are currently displayed. This would be easy to implement and would at least cut down the memory consumption by half. Using a database instead of the in-memory model would make things more complicated and slower.

Stefan Mücke

> Stefan,
>
> Unless I am misunderstanding your explanation, I do not see how the
> objective differs that much.  The Messages Editor plugin is meant to
> allow editing of a group of bundles at the same time.  That group can be
> anything as their loading/location is abstracted.  There are already the
> most common scenarios implemented, like traditional Java .properties
> mechanism and support Eclipse "NL" structure, but one should be able to 
> build implementations for XML, or a Babel SQL database, or all resources
> in the workspace.   It also offers visual cues on bundle group problems
> like missing translations, similar entries, etc.  It also has
> refactoring option (within the bundles), tree-like representation of
> your keys (optional), the ability to show/hide locales (with filter),
> in-sync with the Outline View, wizard for new Locale/bundle, quick view 
> of underlying properties files if need be (like your "Show In"),
> properties formatting options,  etc.
> Again I do not think the intent differs that much... which is ultimately
> to treat all related bundles for each locales as one easy-to-manage
> unit, with value added.
>
> You are right though that your data entry screen (how you edit the
> entries) has no relation to my data entry screen.  But this is just how
> we expose the "model" (e.g. the bundles) for editing.  There is
> potential for lot to be shared in that model.  There is more to be done
> with it (refactoring, warnings, wizards, properties formatting, etc)
> that is not bound to that piece of UI or could share some logic.
>
> As said, a table-like data-entry was already wished for as an addition to
> Messages Editor (well... to its former incarnation: ResoureBundle Editor)
> so if it is to be added to the Messages Editor one day, it may not be
> best to have another editor doing more or less the same thing.  I would
> rather look at your contribution first (if it happens) before
> re-inventing the wheel.
> But yet again, not having much time, it could start with its own life
> until the proper energy is put to combine the contributions.
>
> Pascal Essiembre
>
> -----Original Message-----
> From: babel-dev-bounces@xxxxxxxxxxx
> [mailto:babel-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Mücke
> Sent: July 9, 2008 12:03 AM
> To: Babel committers mailing list
> Subject: RE: [babel-dev] Re: Home for translation tools?
>
>
> Merging the two editors could render some problems, since a different set
> of bundle entries is edited. The main objective of my implementation was
> to be able to see and edit *all* bundles at the same time, no matter
> where they are located. Surely, one could merge the two editors, but
> there would not be a direct relationship between these different tabs.
>
> I think a single table for all resource bundles, as implemented in my
> editor, is sufficient and most convenient for all bundle editing (except
> when key order is to be changed manually). When I localized my RCP
> application, I didn't feel the need to access the individual bundle files
> directly. If direct access, however, is still necessary, one could
> enhance the "Show In" feature to navigate to any bundle (currently only 
> works for the default bundle, because table cells cannot be selected
> individually).
> One could also implement a feature to open my Localization Editor on a
> single or mutiple bundle files directly, have the filters set
> automatically so as to show only that or these bundles.
>
> Looking for another contributor is a good idea.
>
> Stefan Mücke
>
> > I am sadly coming to the same time-constraint conclusions with my
> > Messages Editor plugin.   I realize I have not made any contributions
> > in  quite some time (including bug fix).  I see Stehan plugin ovelaps
> > in  intent (but is otherwise different) with the Messages Editor.  I
> > had on  the agenda to offer a table-like "tab" to the Messages Editor 
> > like  Stephan has done (a feature requested a few times when the
> > plugin was on  SourceForge).   If Stefan plugin was to be contributed,
> > it would be neat  if the two tools could be merged somehow.   I see 
> > offering the ability  to toggle between the two data entry screens
> > within the same "Editor"  (ultimately sharing most of the same code
> > base).   I would love to have  the time to work on this, but I clearly
> > don't.
> > I will try to seek contributors from the former SourceForge plugin
> > community.  Otherwise, I suppose it does not hurt to leave the Messages
> > Editor in the code base until I, or someone else, have more time to
> > pick  it up.
> >
> > Pascal Essiembre
> >
> > -----Original Message-----
> > From: babel-dev-bounces@xxxxxxxxxxx
> > [mailto:babel-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Mücke
> > Sent: July 8, 2008 11:05 PM
> > To: babel-dev@xxxxxxxxxxx
> > Subject: [babel-dev] Re: Home for translation tools?
> >
> >
> > Having my contribution homed in Babel would be okay for me. However, I
> > would love to see such tooling become part of the Eclipse SDK, because
> > it is really helpful for every RCP application that gets localized and
> > also for editing the default bundles (making access to the
> > localization  strings so much easier). Would it be possible to develop
> > the NLS tooling  in Babel and still have it shipped in the Eclipse
> > SDK?
> > I really appreciate being proposed as a committer, but unfortunately
> > my  time doesn't allow to make big contributions. I would be happy if
> > anyone  would pick up my code (even if only as a prototype) to produce
> > something  that can be made available generally.
> >
> >
> > Stefan Mücke
> >
> > > I have a wonderful NLS tooling contribution in PDE Incubator land
> > > but  I  think the better home is in Babel.
> > >
> > > Here is the bug:
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=239475
> > >
> > > In particular, check out the description:
> > > https://bugs.eclipse.org/bugs/attachment.cgi?id=106672
> > >
> > > If everyone agrees, I would love to see Stefan to come on board as a
> > Babel
> > > committer with this wonderful contribution.
> > >
> > > What do y'all think?
> > >
> > > --
> > > Cheers,
> > >
> > > ~ Chris Aniszczyk
> >
> >
> >
> >
> > _______________________________________________
> > babel-dev mailing list
> > babel-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/babel-dev
> >
> >
> > _______________________________________________
> > babel-dev mailing list
> > babel-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/babel-dev
>
>
>
>
> _______________________________________________
> babel-dev mailing list
> babel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/babel-dev
>
>
> _______________________________________________
> babel-dev mailing list
> babel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/babel-dev