[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [babel-dev] Re: Home for translation tools?
|
Title: Message
Personally I am in
favor of merging the two tools. There are a number of significant pieces
of work that need to be done, such as integration with the Babel servers, and I
don't think users will be well served by having two tools.
If we accept that
they ideally should be merged then they need to be in the same project. I
personally would like to see Stefan's work checked into the same plug-in
(i.e. separate packages in the same plug-in, concatenate the plugin.xml files
etc.). Even though the works would not be truly integrated, having
them in the same plug-in would at least start the process of integration.
It also would ensure that users get both, which is essential if we are to get
good user feedback.
As I see
it:
1) The models need
to be merged. This can be done without getting into discussions about the
pros and cons of each UI. From looking at the code, I agree with Stefan
that the data model could easily be merged, assuming in-memory is acceptable
(finding 90MB in a dev. environment I would think would not likely be a
problem),
2) As Pascal
mentioned, we need to abstract out the implementation that fetches
and writes the translations. There are currently three places the
translations are stored 1) the resource bundle files, 2) the Babel server, and
3) the runtime editor keeps a delta containing the edited messages cached
in the local workspace.
3) It would be nice
to unify the two UI approaches but still support the preferable concepts in each
approach. This is going to be rather more time consuming, if only because
the the UI discussions could go on for some time. Starting small, for
example by having both use the same filter dialog and stuff like that, might be
easier.
Furthermore, some of
the code should be shared with the runtime message editor. This would
involve a little refactoring to move some code to a separate
plug-in.
I will have a go at
merging the models and see what I come up with. But I wanted to express my
opinion first because I don't want to spend time on this if the decision is that
they stay separate plug-ins.
Nigel
Westbury