>> It's similar to the translate task from Magesh, but
>> I candidly think it's a little better to translate
>> webapps, since it could translate TOKEN searching
>> in the xml dicts files and also add current lang
>
>Here is what I have observed from my short glance -
>correct me if I am wrong: (T1->my task; T2->your task)
>
>* The configuration file of T2 is XML based,
> while T1 is ResourceBundle (property file) based.
ok
>* T1 fully supports encoding; T2 doesn't seem to be
> supporting encoding in its curent form.
Hum, need to learn more, may be after reading your own
source.
>* T1 supports configurable start and end tokens (though,
> IIRC, it can be just one character each). T2's
> token parsing, AFAICS, is not configurable.
ok, I'll add this two tokens quickly ;)
>* T1 uses multiple hierarchial Resource Bundles; T2 uses
> a single xml file - I can see merits in both approach.
T2 could use a set of xml files, not just one.
There is a not so hidden concept of domain, with a
root domain.
Each xml file concern a domain of translation and
you could search in this domain by tagging like
this __TRANS([EMAIL PROTECTED])__.
Fallback will be in root domain (should add more configure
option here)
If you just have __TRANS(mysearchid)__, translator will
search into all domains, starting from the root one.
>* T1 supports translation of just those files that
> need to be updated (based on timestamps, like <javac>).
> In its current state, T2 doesn't seem to.
T2 have the same feature, since it extend MatchingTask
and use restric :
SourceFileScanner sfs = new SourceFileScanner(this);
files = sfs.restrict(files, srcDir, destDir, m);
>There may be other minor differences as well - I don't
>yet know. But let me ask this: Since the only significant
>difference really seems to be the way the translation text
>is submitted, would it be possible for you to refactor both
>these tasks so that we end up with one single task that
>can be configured using XML files or Resource Bundles,
>retaining the values provided by both these tasks?
>If it doesn't seem feasible, then, perhaps we can
>provide your task too, as an alternative...
That's why one my idea, having Translate just an interface.
XMLTranslate could be an implementation, ditto for ResourceBundles,
and why not a JDBC implementation ?
>> <a href="/welcome__LANG.html">
>> <img src="/images/welcome__LANG.gif" align="left" border="0"
>alt="__TRANS(welcome)
>> __/></a></td>
>
>Using T1, this would be like:
>
><a href="/welcome__#LANG#.html">
><img src="/images/welcome__#LANG#.gif" align="left" border="0"
>alt="#welcome#/></a></td>
>
>> will be translated in french (bienvenue chez nous) and could also
>> adjust needed links (img, href...) :
>>
>> <a href="/welcome__fr.html">
>> <img src="/images/welcome__fr.gif" align="left" border="0"
>alt="bienvenue
>chez
>> nous"/></a></td>
>
>T1's result will be the same, of course.
>
>> if translator name seems incorrect, we could rename it to xtranslate
>> (xml based translate) ....
>
>xtranslate does look good - but, IMHO, if you can
>integrate both these tasks into one, if feasible,
>that would be the best step forward. Let me know
>what you think.
Let's go. I'll try to get translate and translator a
uniq task, with your benediction ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
