[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [babel-dev] Re: Home for translation tools?
|
Stefan, I get your plugin and I am not devaluating it at all in "favor" of
Messages Editor. I do like what it is doing and see the advantages... no
convincing needed. This is why I am saying I always envisioned something
similar offered for the Messages Editor. I do not see why the current
Messages Editor UI would need to get dropped though. It has been made part
of Babel because people saw value for what it is (it was ported from a
successful SourceForge project before). It might need tweaking to
accommodate multiple bundle groups but that is not a reason alone to drop
it. I am talking about enhancing it. The Messages Editor UI offers a
different perspective for those needing large fields to edit right away
(with no real need to see all values at once). It offers room for different
visual cues for each key value fields (missing entries, duplicates, etc) and
ultimately more should be added (like cues for non-translatable values,
etc). "Comment" support (bundle group wide or just for specific key local
should also get added as fields or else somehow...) you just have more
visual estate to do fancy things when only showing the fields that pertains
to a given key. Because it is not meant to see all values at once does not
mean it is of no use to anyone. Both have really good advantages depending
on your usage/need at any moment. I do not see why we should sacrifice one
for the other. I would like to offer both and I do not see a problem there
(other than time of course). By the way, quick key finding is an existing
feature of the ResourceBundle editor not yet ported over (but just finding
one key). There is no reason to think allowing more enhanced key filtering
capabilities to end up with just a subset of keys to work with would be
unrealistic to have for Messages Editor as well.
Thank you,
Pascal Essiembre
-----Original Message-----
From: babel-dev-bounces@xxxxxxxxxxx [mailto:babel-dev-bounces@xxxxxxxxxxx]
On Behalf Of Stefan Mücke
Sent: July 9, 2008 6:18 PM
To: Babel committers mailing list
Subject: RE: [babel-dev] Re: Home for translation tools?
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
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
