You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by GOMEZ Henri <hg...@slib.fr> on 2002/05/02 21:02:18 UTC

translate/translator task - suggestions

Hi,

I was thinking about merge of translate and translator
tasks and have the following ruminations :

- Translator have a concept of domains, so you could
  search for a translation into all domains loaded,
  or a specific domain.

  There is a root (default) domain, where translator
  search when :

  - Initially if no domain is given for lookup.
  - Fallback search when an entry is not found in the
    specified domain.

My idea was to add to each xml files and/or also in 
properties implementations, a way to specify the fallback
domain to search for.

Let say that we have 4 domains: A, B, C, D
    
A is the root domain

B is a std domain, with no special fallback,
  it's fallback will be A (root domain)

C is another std domain, with B as fallback

D is std domain with no fallback


- search in domain D, will make task search
in D and failed if nothing is found here.

- search in domain C, will make task search 
  in C, B and finally A

- search in domain B, will make task search
  in B then A.

- search in A will allways be final.

- search without domain given will make task
  search first in A, and then in B,C,D sequentially.

The fallback tag is easy to add in xml based files,
but how to do this in properties bundle implementation ?

Should we tag each bundle res with a fallback tag in
task properties ?

The domain idea is important when you want to translate
a big webapp where dictionaries are splitted between
developpers and when you can have such fallback strategy,
ie some globals dictionaries and local dictionnaries.

-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: translate/translator task - suggestions

Posted by Magesh Umasankar <um...@apache.org>.
----- Original Message ----- 
From: "GOMEZ Henri" <hg...@slib.fr>


> - Translator have a concept of domains, so you could
>   search for a translation into all domains loaded,
>   or a specific domain.
> 
>   There is a root (default) domain, where translator
>   search when :
> 
>   - Initially if no domain is given for lookup.
>   - Fallback search when an entry is not found in the
>     specified domain.

IMHO, the concept of root and fallback has been
defined nicely to follow a hierarchial beanch-2-branch
pattern as explained in 
http://java.sun.com/products/jdk/1.2/docs/api/java/util/ResourceBundle.html

If you can have your XML Dictionary files follow this pattern,
it would be peachy!  Or is there something that I do
not follow that makes you shrug this commonly followed
'standard'?

> The fallback tag is easy to add in xml based files,
> but how to do this in properties bundle implementation ?

Using the naming of the files.

> 
> Should we tag each bundle res with a fallback tag in
> task properties ?

Nope.  It is taken care automatically.

> 
> The domain idea is important when you want to translate
> a big webapp where dictionaries are splitted between
> developpers and when you can have such fallback strategy,
> ie some globals dictionaries and local dictionnaries.

Yep, it is important...  and I assume they will end up
being hierarchially defined ;-)

Side note:
Does your task reparse all files if the relevant 
Config file has been changed as well?  Or does it
reparse a generated file only if the source file is 
newer?

> 
> Henri Gomez                 ___[_]____

Cheers,
Magesh

*************************************************************
*  Optimist: A person who while falling from the            *
*  Eiffel tower says in midway "See I am not injured yet."  *
*************************************************************



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>