[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nuxeo-localizer] LocalFolder in the CVS!! (0.8.1 coming..)
From: |
Juan David Ibáñez Palomar |
Subject: |
Re: [Nuxeo-localizer] LocalFolder in the CVS!! (0.8.1 coming..) |
Date: |
Thu, 21 Feb 2002 15:32:15 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 |
Luistxo Fernandez wrote:
I couldn't wait and last night implemented LocalFolder, it's a folder with
two new tabs in the management screens. Quick start:
So at the end it is LocalFolder and not LocalObject
Yes, after all it's a folder. And you can manage more than one
multilingual object.
4. Go to the "Contents" tab and create two Python scripts named "test_en"
and "test_es", the first one could return "Hello world!", the second one
could return "°Hola mundo!";
I thought, from a previous msg of yours, that it would work without those
_es/_en/... additions to the IDs of the objects, just placing objects with the
same in the different folders....
I changed my opinion again, I do it often, specially in the earlier
stages of development.
The reason here is because a class I still haven't talked about, it's
name will probably be
"Locale". It will provide a solution for dates, money, etc.. You can
look it in the source
code, "Locale.py". It looks like this:
class Locale:
def date_short_en(self, datetime):
return ...
def date_short_es(self, datetime):
return ...
The class "Locale" is in a very early stage of development.
Actually, implementing "LocalFolder" was very easy as the
infraestructure was
already there. I've to document this, I'll sent a message with examples
of what
can be done from the file system.
LocaleFolder + LocalContent + MessageCatalogs makes the Localizer class
unnecessary now, I think. No more /Z/manage to work with localised zopesites.
Yes!! no more "/Z/manage". However, you still will need the Localizer class.
However, I have one doubt. With the Localizer class you could set an overall
language-default for a given site. Now, each element (LocalContent,
LocalFolder...) may have different defaults? Isn´t it risky? If you are not
careful, it may lead to inconsistencies...
In version 0.8.2 the Localizer meta type still will exist and you will
have one in the root
of each multilingual web site. It will let to set these defaults.
Actually it will be used
for language negotiation.
Right now, if you have a MessageCatalog named "msg" you can type
"msg.changeLanguageForm()"
to get the well known selection box. It won't be possible in 0.8.2,
because I will remove this
feature from the mixin class "LanguageManager" and move it to "Localizer".
This means that you'll have a Localizer instance in the root of your web
site, and you will type
"Localizer.changeLanguageForm()". This instance also will let you to
cutomize the language
negotiation policy of your web site, a feature that Gari requested in a
previous message, he
gave the example of "possitive discrimination of a given language".
But the "Localizer" class of 0.8.2 won't rewrite the url, no more
"/Z/manage".
So the meta types in 0.8.2 will be:
- Localizer (for language negotiation)
- MessageCatalog (to translate software: presentation and logic)
- LocalContent (to manage multilingual text)
- LocalFolder (generic solution, to be used when the previous can't be used)
I still don't know were to put the locale stuff (dates, money, etc..).
Luistxo
_______________________________________________
Nuxeo-localizer mailing list
address@hidden
http://mail.freesoftware.fsf.org/mailman/listinfo/nuxeo-localizer
--
J. David Ib??ez, Nuxeo.com
Python programmer (http://www.python.org)