Re: [Nuxeo-localizer] Proposal: local object

[Juan David Ibáñez Palomar]

Luistxo wrote:

> Right now we use differently localised methods to render dates, for 
> things like the example that David proposes.
>
> In DTML we write: <dtml-var "LongDate(bobobase_modification_time)">
>
> And in the language folders that come with Localizer we have different 
> LongDate methods. The English folder 'en' contains one of the 
> hardcoded functions to render a given date, and in the Basque folder 
> 'eu' we have a more complicated method, that calls a specific python 
> script, a dictionary of month names, etc.
>
> The only difference that I spot in David's proposal is that those 
> divergent methods would now placed in the same folder and are marked 
> as _en or _eu in their ID.

Actually I've changed my opinion (technical reasons), the new object
would contain a folder for each language (as the "Localizer" class).
For example:

 date/
   en/
     long
     short
   es/
     long
     short


The problem with the "Localizer" class is that it's difficult to use and
difficult to make it work with virtual hosting. At least I still don't
understand it completely.

This is the difference, the new object would be easier to use and less
problematic.

I would like to get rid of the "Localizer" class, if possible.


> > Imagine a folder with two new management screens, one of
> > them would be the well known "Languages", the other one
> > one could be called "Local attributes".
> >
> > The name of the folder could be "date".
> >
> > Imagine we define two languages for "date": "en" and "es".
> > And two local attributes: "short" and "long".
> >
> > Then we add to it the Python scripts "short_es", "short_en",
> > "long_es" and "long_en". As you already guessed this methods
> > get a DateTime instance as parameter and return a string with
> > a short or long representation of the date in spanish or english.
> >
> > Then you could use the object this way:
> >
> >  <dtml-var "date.short(bobobase_modification_time)">
> >  <dtml-var "date.long(bobobase_modification_time)">
> >
> > You also could store other objects: images, files, etc..
>
>
> I think that this may work when there is 1<>1 object correspondency. I 
> don't know if I am mistaken.
>
> But it may well happen that, in order to render something you need
>
> * for locale A a method that calls another method plus 2 or 3 
> pythonscripts
> * for locale B, just a simple method.
>
> That is the case, for instance with some Basque date formats, as 
> compared with English ones. The present architecture of Localizer 
> let´s us handle this thorugh the locale/language folders. Would the 
> new feature improve this? Could it work with a 1<>4 object 
> correspondency?

I think it would work, for example:

 date/
   en/
     long
   eu/
     long
     aux1
     aux2

The "long" method in "eu" would call "aux1" and "aux2" to do the job:

 container.aux1(..)
 ..

Is this ok?


> Luistxo
>
> PD. I've just invented this term "object correspondency". Obviously 
> I'm not an English native speaker neither computer-savvy...
>
> PPD. I hate these lists where the automated reply doesn't go to the 
> list :-)

Yes, this is the default configuration of Mailman, good for big lists
with lot of traffic. I've changed it.


--
J. David Ibáñez, Nuxeo.com
Python programmer (http://www.python.org)