Posted by
Jacques Le Roux on
URL: http://ofbiz.116.s1.nabble.com/AW-Re-OFBiz-Dev-Question-on-i18n-of-Entity-labels-tp165701p165704.html
Tapio,
I'm sorry too because I guess I'm not clear enough. By core data I mean seed
data (vs demo data). Entity like enumeration, statusItem, etc. Often these
data populate drop-down boxes and they are needed at the core of OFBiz to
make it work.
To be clear, localised demo data may be managed like Peter explained below
but seed data (or core data like I called them) can't be managed like this
because of multi-locale site (although perhaps an enhancement mau be
possible ?)
My concern is that if you change, add or suppress data in the files that
feed the data base intially nothing (no mechanim) will tell you to change
the localized data in the related properties files. That's what I'm looking
for, any idea ? Perhaps I miss something here as I'm almost a newbie in Java
?
Jacques
----- Original Message -----
From: "Tapio Reisinger" <
[hidden email]>
To: "OFBiz Project Development Discussion" <
[hidden email]>
Sent: Tuesday, July 19, 2005 9:26 PM
Subject: Re: [OFBiz] Dev - Question on i18n of Entity labels
> Sorry, maybe I misunderstand you. What exactly do you mean with core data?
>
> Regards
> Tapio
>
> Jacques Le Roux schrieb:
> > Thanks Tapio for you suggestion. I was thinking about core data, and I
don't
> > think that it's user job to do that, don't you ?
> >
> > Although I agree that it will be less pain to delegate localization
tasks to
> > other people than developper. Only localization skill is involved with a
> > solution like yours, no more is needed ! But before that we need to
develop
> > something, egg and hen problem...
> >
> > Let's see what others think about it, and if my intuition is worth
> > something.
> >
> > Jacques
> >
> > ----- Original Message -----
> > From: "Tapio Reisinger" <
[hidden email]>
> > To: <
[hidden email]>
> > Sent: Tuesday, July 19, 2005 4:51 PM
> > Subject: AW: Re: [OFBiz] Dev - Question on i18n of Entity labels
> >
> >
> >
> >>Jacques,
> >>
> >>I agree with you. For me it would be much better to maintain
descriptions
> >
> > by the user in the screen and not by the developer in the property
files.
> >
> >>My suggestion is to create for each entity which needs localized data, a
> >
> > text entity extension. Thist text entity consists the key from the
entity,
> > which needs the localized data, the language key (DE or FR) and the
> > description.
> >
> >>Regards
> >>Tapio
> >>
> >>
> >>>Thanks Peter for this explanation, I must admit that I was not clear. I
> >
> > was
> >
> >>>asking myself if it will not be easier to maintain localized data at a
> >
> > root
> >
> >>>level in the futur. I was not thinking about demo datas but core datas.
I
> >>>have no solution to propose, it was just an inner question (intuitive),
> >
> > with
> >
> >>>a little argument for others thought... I feel that there is something
> >
> > there
> >
> >>>but I can't argue more for the moment, perhaps I'm wrong ;o)
> >>>
> >>>Jacques
> >>>
> >>>
> >>>----- Original Message -----
> >>>From: "Peter Goron"
> >>>To: "OFBiz Project Development Discussion"
> >>>Sent: Tuesday, July 19, 2005 3:07 PM
> >>>Subject: Re: [OFBiz] Dev - Question on i18n of Entity labels
> >>>
> >>>
> >>>
> >>>>Hi David,
> >>>>
> >>>>I will complete Jacques message about i18n of entity data in neogia
> >>>>project.
> >>>>
> >>>>In order to localized demo data, we have extended entity engine to
> >
> > allow
> >
> >>>>loading of localized data files instead of original ones.
> >>>>
> >>>>Example :
> >>>>java -jar ofbiz.jar -install -locale=fr_FR
> >>>>
> >>>>When Entity data loader will load DemoProduct.xml :
> >>>>First it will try to load DemoProduct_fr_FR.xml if present,
> >>>>else it will try to load DemoProduct_fr.xml if present,
> >>>>else it will fallback to DemoProduct.xml
> >>>>
> >>>>This extension is not intended to replace existing solutions to
> >>>>localized entity data because this solution is not applicable to a
> >>>>multi-locale site.
> >>>>
> >>>>Peter
> >>>>
> >>>>
> >>>>Jacques, cvs and branches are not related to i18n stuff. It's a better
> >>>>way to track ofbiz evolution instead of keeping a lot of synchronized
> >>>>patches.
> >>>>
> >>>>Le mardi 19 juillet 2005 à 07:09 -0500, David E. Jones a écrit :
> >>>>
> >>>>>Hmmm... You lost me. What is it that you are proposing?
> >>>>>
> >>>>>-David
> >>>>>
> >>>>>
> >>>>>On Jul 19, 2005, at 1:33 AM, Jacques Le Roux wrote:
> >>>>>
> >>>>>
> >>>>>>Some days before, I asked this question on Jira. Without any
> >>>>>>comment, I ask
> >>>>>>it one more time.
> >>>>>>
> >>>>>>After have done this job (Jira OFBIZ-356), I asked myself if it was
> >>>>>>the
> >>>>>>right way to manage i18n of Entity. I think we should manage i18n
> >>>>>>and l10n
> >>>>>>of this data at root. Entity datas in DB came initially from xml
> >>>>>>data files
> >>>>>>which are in data directory of each component. I think we shoud
> >>>>>>create a new
> >>>>>>(even replacement) mechanism (or even an architecture) that takes
> >>>>>>account of
> >>>>>>this fact.
> >>>>>>
> >>>>>>For example, people of Néréides (France) have already taken this
> >
> > into
> >
> >>>>>>account and have created branchs in CVS for Neogia to manage it in
> >>>>>>their own
> >>>>>>global ant job which merges their components with OFBiz components
> >>>>>>(OFBiz
> >>>>>>components remain most part of Neogia actually).
> >>>>>>
> >>>>>>What do you think about that ? Any idea, objection ?
> >>>>>>
> >>>>>>Jacques
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Dev mailing list
> >>>>
[hidden email]
> >>>><a
> >>
>
>>href="
http://lists.ofbiz.org/mailman/listinfo/dev">
http://lists.ofbiz.org/m
m
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev