You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Fabián Mandelbaum <fm...@gmail.com> on 2008/09/06 19:11:42 UTC
David's Model and translation projects
Hello there,
I'm considering David's Model
(http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering how
would David handle translations of documents.
Let's say I have a file, for example: file.xml which is written in
English, and I want to store its translation to, say, Spanish. Which
would be the recommended storage model?
1) Common storage place
/content/file.xml (English version)
/content/file-es.xml (Spanish version)
/content/file-fr.xml (French version)
2) Folders for each language
/content/en/file.xml
/content/es/file.xml
/content/fr/file.xml
3) Workspaces for each language
/content/file.xml (in 'en' workspace)
/content/file.xml (in 'es' workspace)
/content/file.xml (in 'fr' workspace)
Other? My ears are open, Thanks in advance.
Re: David's Model and translation projects
Posted by Fabián Mandelbaum <fm...@gmail.com>.
OK Alex, thanks!
Alexander Klimetschek escribió:
> On Mon, Sep 8, 2008 at 2:45 PM, Fabián Mandelbaum <fm...@gmail.com> wrote:
>
>> Ard,
>>
>> one thing I forgot to ask: is this 'filter' thing available
>> somewhere? Is it part of JR1.5?
>>
>
> No, that is purely theoretical, nothing in Jackrabbit and not planned.
> But it shouldn't be difficult to look for a specific language folder
> and display its contents, if present, or fall back to the default
> language (or the current folder).
>
> Regards,
> Alex
>
RE: David's Model and translation projects
Posted by Ard Schrijvers <a....@onehippo.com>.
> > Ard,
> >
> > one thing I forgot to ask: is this 'filter' thing available
> > somewhere? Is it part of JR1.5?
>
> No, that is purely theoretical, nothing in Jackrabbit and not planned.
It is part of a virtual layer we build on top of Jackrabbit, but not
part of Jackrabbit indeed
-Ard
> But it shouldn't be difficult to look for a specific language
> folder and display its contents, if present, or fall back to
> the default language (or the current folder).
>
> Regards,
> Alex
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
Re: David's Model and translation projects
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Sep 8, 2008 at 2:45 PM, Fabián Mandelbaum <fm...@gmail.com> wrote:
> Ard,
>
> one thing I forgot to ask: is this 'filter' thing available
> somewhere? Is it part of JR1.5?
No, that is purely theoretical, nothing in Jackrabbit and not planned.
But it shouldn't be difficult to look for a specific language folder
and display its contents, if present, or fall back to the default
language (or the current folder).
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: David's Model and translation projects
Posted by Fabián Mandelbaum <fm...@gmail.com>.
Ard,
one thing I forgot to ask: is this 'filter' thing available
somewhere? Is it part of JR1.5?
thanks in advance.
Ard Schrijvers escribió:
> Hello Fabián Mandelbaum,
>
> First of all, IMHO, you do not have to entirely commit to David's model. IMHO, some of the rules are based on the frontend technology that is displaying the data (like number 4, beware of same name siblings. When creating frontends based on repository paths and cache them etc etc, I understand same name siblings are nasty, but, AFAICS, it is a frontend technology driven rule. Same holds for some other rules.)
>
> So, in your case, I would preferably not structure your content in folders containing the 'language' name. As you said, you break one of Davids Rules (though, again, creating some basic structure doesn't seem harmful to me at all, again :-)) ), but worse, you might run into cumbersome queries regarding performance. You probably will need to do all queries having some path info, slowing queries significantly.
>
> I would create same name sibblings, and have meta data (a property) on the file indicate the language. I must admit you might want to have some features for this we have added on top of Jackrabbit, like 'filtered mirrors': below some node, we expose a virtual copy of the repository, filtered on some properties to only show those nodes you want to. All nodes in this virtual layer are accessed jsr compliant, so, the client isn't even aware (we call this a facetselect, a mirror with filters, where we also expose facetsearches, a virtual facetted navigation within Jackrabbit, again jsr compliant). Though even without this enhancement I would go for same name sibblings and meta data. Querying on meta data is alsways fast, as opposed to querying with path info.
>
> Just my 2 cents,
>
> Regards Ard
>
>
>
>> Fabián Mandelbaum wrote:
>> Approach #2 is indeed, natural, however the "problem" I see
>> with approach #2 is that it seems to break David's rule #1
>> (data 1st vs.
>> structure 1st) by imposing a fixed content structure to
>> projects (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
>>
>> I'm not saying I won't end doing things this way (actually,
>> it is so far my personal choice), I just wanted to know if
>> there was a way to do it in a way that conforms a bit more to
>> David's rule #1.
>>
>> Thanks again.
>>
>> Tobias Bocanegra escribió:
>>
>>> hi,
>>> it certainly depends on your intention, but having a folder
>>>
>> for each
>>
>>> language is imo the best approach. you might have other resources
>>> later (like images) that are language dependent that you can put in
>>> the folder.
>>>
>>> regards, toby
>>>
>>> On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
>>>
>>>
>>>> Hello there,
>>>>
>>>> I'm considering David's Model
>>>> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering
>>>> how would David handle translations of documents.
>>>>
>>>> Let's say I have a file, for example: file.xml which
>>>>
>> is written
>>
>>>> in English, and I want to store its translation to, say, Spanish.
>>>> Which would be the recommended storage model?
>>>>
>>>> 1) Common storage place
>>>>
>>>> /content/file.xml (English version)
>>>> /content/file-es.xml (Spanish version)
>>>> /content/file-fr.xml (French version)
>>>>
>>>> 2) Folders for each language
>>>>
>>>> /content/en/file.xml
>>>> /content/es/file.xml
>>>> /content/fr/file.xml
>>>>
>>>> 3) Workspaces for each language
>>>>
>>>> /content/file.xml (in 'en' workspace)
>>>> /content/file.xml (in 'es' workspace)
>>>> /content/file.xml (in 'fr' workspace)
>>>>
>>>> Other? My ears are open, Thanks in advance.
>>>>
>>>>
>>>>
>>
Re: David's Model and translation projects
Posted by Fabián Mandelbaum <fm...@gmail.com>.
OK, I'll make sure my XPath queries have the lang attribute somewhere to
limit queries to a given lang.
Thanks!
Ard Schrijvers escribió:
>
>> OTOH, my file node (extending nt:file) already has the
>> lang as metadata (a property). I'm doing tests both extending
>> nt:file (1st
>> attempt) and nt:resource (as David suggests), I don't really
>> find any difference, though I know there may be some
>> difference in performance, or compatibility, I don't know...
>>
>>
>
> The performance difference will not be in there, but in queries based on
> path locations, like 'give me the last 10 news articles below
> /content/english/news'. Because you do not want news articles below
> /content/dutch/news, you have to add this path constraint to the query,
> and that makes it slower for increasing numbers of nodes. Though, as you
> mailed, you also have the language as a propery on the nodes, so make
> sure you add this in the where clause of your searches, to limit the
> number of hits only to the language you are looking for
>
> -Ard
>
>
>>
>>
RE: David's Model and translation projects
Posted by Ard Schrijvers <a....@onehippo.com>.
> OTOH, my file node (extending nt:file) already has the
> lang as metadata (a property). I'm doing tests both extending
> nt:file (1st
> attempt) and nt:resource (as David suggests), I don't really
> find any difference, though I know there may be some
> difference in performance, or compatibility, I don't know...
>
The performance difference will not be in there, but in queries based on
path locations, like 'give me the last 10 news articles below
/content/english/news'. Because you do not want news articles below
/content/dutch/news, you have to add this path constraint to the query,
and that makes it slower for increasing numbers of nodes. Though, as you
mailed, you also have the language as a propery on the nodes, so make
sure you add this in the where clause of your searches, to limit the
number of hits only to the language you are looking for
-Ard
>
Re: David's Model and translation projects
Posted by Fabián Mandelbaum <fm...@gmail.com>.
Hello Ard, Tobías,
first of all, let me thank you for your answers. After reading
Tobías answer to rule #1 and then reading Ard's I realized that I may
have misunderstood the 'data vs. structure' thing, and thank you both
for your clarifications.
OTOH, my file node (extending nt:file) already has the lang as
metadata (a property). I'm doing tests both extending nt:file (1st
attempt) and nt:resource (as David suggests), I don't really find any
difference, though I know there may be some difference in performance,
or compatibility, I don't know...
I'll ponder the pros and cons of both approachs (folders vs. SNS)
and perform tests with both.
Thanks again for your prompt and accurate answers.
Tobias Bocanegra escribió:
> On 9/8/08, Ard Schrijvers <a....@onehippo.com> wrote:
>
>> Hello Fabián Mandelbaum,
>>
>> First of all, IMHO, you do not have to entirely commit to David's model. IMHO, some of the rules are based on the frontend technology that is displaying the data (like number 4, beware of same name siblings. When creating frontends based on repository paths and cache them etc etc, I understand same name siblings are nasty, but, AFAICS, it is a frontend technology driven rule. Same holds for some other rules.)
>>
>> So, in your case, I would preferably not structure your content in folders containing the 'language' name. As you said, you break one of Davids Rules (though, again, creating some basic structure doesn't seem harmful to me at all, again :-)) ), but worse, you might run into cumbersome queries regarding performance. You probably will need to do all queries having some path info, slowing queries significantly.
>>
>> I would create same name sibblings, and have meta data (a property) on the file indicate the language. I must admit you might want to have some features for this we have added on top of Jackrabbit, like 'filtered mirrors': below some node, we expose a virtual copy of the repository, filtered on some properties to only show those nodes you want to. All nodes in this virtual layer are accessed jsr compliant, so, the client isn't even aware (we call this a facetselect, a mirror with filters, where we also expose facetsearches, a virtual facetted navigation within Jackrabbit, again jsr compliant). Though even without this enhancement I would go for same name sibblings and meta data. Querying on meta data is alsways fast, as opposed to querying with path info.
>>
>
>
> the nice thing about not having SNS and having a folder structure for
> the language is that you can easily access it via webdav. so you just
> drop your translated files in the respective folder again, and your
> done. having SNS and meta data just renders this impossible.
>
> regards, toby
>
> ps: imo SNS were a stupid idea (the way they were speced in jcr1.0.
> there are some efforts in jsr283 to correct this) and are actually
> only valid to use when importing/exploding XML files into the
> repository. but you always have troubles as soon as you have SNS, and
> you need a lot of application logic to handle and use them
> efficiently.
>
>
>
>> Just my 2 cents,
>>
>> Regards Ard
>>
>>
>>
>> > Fabián Mandelbaum wrote:
>> > Approach #2 is indeed, natural, however the "problem" I see
>> > with approach #2 is that it seems to break David's rule #1
>> > (data 1st vs.
>> > structure 1st) by imposing a fixed content structure to
>> > projects (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
>> >
>> > I'm not saying I won't end doing things this way (actually,
>> > it is so far my personal choice), I just wanted to know if
>> > there was a way to do it in a way that conforms a bit more to
>> > David's rule #1.
>> >
>> > Thanks again.
>> >
>> > Tobias Bocanegra escribió:
>> > > hi,
>> > > it certainly depends on your intention, but having a folder
>> > for each
>> > > language is imo the best approach. you might have other resources
>> > > later (like images) that are language dependent that you can put in
>> > > the folder.
>> > >
>> > > regards, toby
>> > >
>> > > On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
>> > >
>> > >> Hello there,
>> > >>
>> > >> I'm considering David's Model
>> > >> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering
>> > >> how would David handle translations of documents.
>> > >>
>> > >> Let's say I have a file, for example: file.xml which
>> > is written
>> > >> in English, and I want to store its translation to, say, Spanish.
>> > >> Which would be the recommended storage model?
>> > >>
>> > >> 1) Common storage place
>> > >>
>> > >> /content/file.xml (English version)
>> > >> /content/file-es.xml (Spanish version)
>> > >> /content/file-fr.xml (French version)
>> > >>
>> > >> 2) Folders for each language
>> > >>
>> > >> /content/en/file.xml
>> > >> /content/es/file.xml
>> > >> /content/fr/file.xml
>> > >>
>> > >> 3) Workspaces for each language
>> > >>
>> > >> /content/file.xml (in 'en' workspace)
>> > >> /content/file.xml (in 'es' workspace)
>> > >> /content/file.xml (in 'fr' workspace)
>> > >>
>> > >> Other? My ears are open, Thanks in advance.
>> > >>
>> > >>
>> >
>> >
>>
>>
RE: David's Model and translation projects
Posted by Ard Schrijvers <a....@onehippo.com>.
> Tobias Bocanegra wrote:
> the nice thing about not having SNS and having a folder
> structure for the language is that you can easily access it
> via webdav. so you just drop your translated files in the
> respective folder again, and your done. having SNS and meta
> data just renders this impossible.
Unless you access the repository through a node that exposes the content through a filtered mirror, only showing you the language you are looking for, but this is not default Jackrabbit functionality I agree :-)
-Ard
>
> regards, toby
>
> ps: imo SNS were a stupid idea (the way they were speced in jcr1.0.
> there are some efforts in jsr283 to correct this) and are
> actually only valid to use when importing/exploding XML files
> into the repository. but you always have troubles as soon as
> you have SNS, and you need a lot of application logic to
> handle and use them efficiently.
>
>
> >
> > Just my 2 cents,
> >
> > Regards Ard
> >
> >
> >
> > > Fabián Mandelbaum wrote:
> > > Approach #2 is indeed, natural, however the "problem" I
> see > with
> > approach #2 is that it seems to break David's rule #1 >
> (data 1st vs.
> > > structure 1st) by imposing a fixed content structure to
> > projects
> > (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
> > >
> > > I'm not saying I won't end doing things this way
> (actually, > it
> > is so far my personal choice), I just wanted to know if >
> there was a
> > way to do it in a way that conforms a bit more to >
> David's rule #1.
> > >
> > > Thanks again.
> > >
> > > Tobias Bocanegra escribió:
> > > > hi,
> > > > it certainly depends on your intention, but having a folder >
> > for each > > language is imo the best approach. you might
> have other
> > resources > > later (like images) that are language dependent that
> > you can put in > > the folder.
> > > >
> > > > regards, toby
> > > >
> > > > On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
> > > >
> > > >> Hello there,
> > > >>
> > > >> I'm considering David's Model
> > > >> (http://wiki.apache.org/jackrabbit/DavidsModel) and was
> > wondering > >> how would David handle translations of documents.
> > > >>
> > > >> Let's say I have a file, for example: file.xml which
> > > is written
> > > >> in English, and I want to store its translation to,
> say, Spanish.
> > > >> Which would be the recommended storage model?
> > > >>
> > > >> 1) Common storage place
> > > >>
> > > >> /content/file.xml (English version)
> > > >> /content/file-es.xml (Spanish version)
> > > >> /content/file-fr.xml (French version)
> > > >>
> > > >> 2) Folders for each language
> > > >>
> > > >> /content/en/file.xml
> > > >> /content/es/file.xml
> > > >> /content/fr/file.xml
> > > >>
> > > >> 3) Workspaces for each language
> > > >>
> > > >> /content/file.xml (in 'en' workspace)
> > > >> /content/file.xml (in 'es' workspace)
> > > >> /content/file.xml (in 'fr' workspace)
> > > >>
> > > >> Other? My ears are open, Thanks in advance.
> > > >>
> > > >>
> > >
> > >
> >
>
Re: David's Model and translation projects
Posted by Tobias Bocanegra <to...@day.com>.
On 9/8/08, Ard Schrijvers <a....@onehippo.com> wrote:
> Hello Fabián Mandelbaum,
>
> First of all, IMHO, you do not have to entirely commit to David's model. IMHO, some of the rules are based on the frontend technology that is displaying the data (like number 4, beware of same name siblings. When creating frontends based on repository paths and cache them etc etc, I understand same name siblings are nasty, but, AFAICS, it is a frontend technology driven rule. Same holds for some other rules.)
>
> So, in your case, I would preferably not structure your content in folders containing the 'language' name. As you said, you break one of Davids Rules (though, again, creating some basic structure doesn't seem harmful to me at all, again :-)) ), but worse, you might run into cumbersome queries regarding performance. You probably will need to do all queries having some path info, slowing queries significantly.
>
> I would create same name sibblings, and have meta data (a property) on the file indicate the language. I must admit you might want to have some features for this we have added on top of Jackrabbit, like 'filtered mirrors': below some node, we expose a virtual copy of the repository, filtered on some properties to only show those nodes you want to. All nodes in this virtual layer are accessed jsr compliant, so, the client isn't even aware (we call this a facetselect, a mirror with filters, where we also expose facetsearches, a virtual facetted navigation within Jackrabbit, again jsr compliant). Though even without this enhancement I would go for same name sibblings and meta data. Querying on meta data is alsways fast, as opposed to querying with path info.
the nice thing about not having SNS and having a folder structure for
the language is that you can easily access it via webdav. so you just
drop your translated files in the respective folder again, and your
done. having SNS and meta data just renders this impossible.
regards, toby
ps: imo SNS were a stupid idea (the way they were speced in jcr1.0.
there are some efforts in jsr283 to correct this) and are actually
only valid to use when importing/exploding XML files into the
repository. but you always have troubles as soon as you have SNS, and
you need a lot of application logic to handle and use them
efficiently.
>
> Just my 2 cents,
>
> Regards Ard
>
>
>
> > Fabián Mandelbaum wrote:
> > Approach #2 is indeed, natural, however the "problem" I see
> > with approach #2 is that it seems to break David's rule #1
> > (data 1st vs.
> > structure 1st) by imposing a fixed content structure to
> > projects (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
> >
> > I'm not saying I won't end doing things this way (actually,
> > it is so far my personal choice), I just wanted to know if
> > there was a way to do it in a way that conforms a bit more to
> > David's rule #1.
> >
> > Thanks again.
> >
> > Tobias Bocanegra escribió:
> > > hi,
> > > it certainly depends on your intention, but having a folder
> > for each
> > > language is imo the best approach. you might have other resources
> > > later (like images) that are language dependent that you can put in
> > > the folder.
> > >
> > > regards, toby
> > >
> > > On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
> > >
> > >> Hello there,
> > >>
> > >> I'm considering David's Model
> > >> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering
> > >> how would David handle translations of documents.
> > >>
> > >> Let's say I have a file, for example: file.xml which
> > is written
> > >> in English, and I want to store its translation to, say, Spanish.
> > >> Which would be the recommended storage model?
> > >>
> > >> 1) Common storage place
> > >>
> > >> /content/file.xml (English version)
> > >> /content/file-es.xml (Spanish version)
> > >> /content/file-fr.xml (French version)
> > >>
> > >> 2) Folders for each language
> > >>
> > >> /content/en/file.xml
> > >> /content/es/file.xml
> > >> /content/fr/file.xml
> > >>
> > >> 3) Workspaces for each language
> > >>
> > >> /content/file.xml (in 'en' workspace)
> > >> /content/file.xml (in 'es' workspace)
> > >> /content/file.xml (in 'fr' workspace)
> > >>
> > >> Other? My ears are open, Thanks in advance.
> > >>
> > >>
> >
> >
>
RE: David's Model and translation projects
Posted by Ard Schrijvers <a....@onehippo.com>.
Hello Fabián Mandelbaum,
First of all, IMHO, you do not have to entirely commit to David's model. IMHO, some of the rules are based on the frontend technology that is displaying the data (like number 4, beware of same name siblings. When creating frontends based on repository paths and cache them etc etc, I understand same name siblings are nasty, but, AFAICS, it is a frontend technology driven rule. Same holds for some other rules.)
So, in your case, I would preferably not structure your content in folders containing the 'language' name. As you said, you break one of Davids Rules (though, again, creating some basic structure doesn't seem harmful to me at all, again :-)) ), but worse, you might run into cumbersome queries regarding performance. You probably will need to do all queries having some path info, slowing queries significantly.
I would create same name sibblings, and have meta data (a property) on the file indicate the language. I must admit you might want to have some features for this we have added on top of Jackrabbit, like 'filtered mirrors': below some node, we expose a virtual copy of the repository, filtered on some properties to only show those nodes you want to. All nodes in this virtual layer are accessed jsr compliant, so, the client isn't even aware (we call this a facetselect, a mirror with filters, where we also expose facetsearches, a virtual facetted navigation within Jackrabbit, again jsr compliant). Though even without this enhancement I would go for same name sibblings and meta data. Querying on meta data is alsways fast, as opposed to querying with path info.
Just my 2 cents,
Regards Ard
> Fabián Mandelbaum wrote:
> Approach #2 is indeed, natural, however the "problem" I see
> with approach #2 is that it seems to break David's rule #1
> (data 1st vs.
> structure 1st) by imposing a fixed content structure to
> projects (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
>
> I'm not saying I won't end doing things this way (actually,
> it is so far my personal choice), I just wanted to know if
> there was a way to do it in a way that conforms a bit more to
> David's rule #1.
>
> Thanks again.
>
> Tobias Bocanegra escribió:
> > hi,
> > it certainly depends on your intention, but having a folder
> for each
> > language is imo the best approach. you might have other resources
> > later (like images) that are language dependent that you can put in
> > the folder.
> >
> > regards, toby
> >
> > On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
> >
> >> Hello there,
> >>
> >> I'm considering David's Model
> >> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering
> >> how would David handle translations of documents.
> >>
> >> Let's say I have a file, for example: file.xml which
> is written
> >> in English, and I want to store its translation to, say, Spanish.
> >> Which would be the recommended storage model?
> >>
> >> 1) Common storage place
> >>
> >> /content/file.xml (English version)
> >> /content/file-es.xml (Spanish version)
> >> /content/file-fr.xml (French version)
> >>
> >> 2) Folders for each language
> >>
> >> /content/en/file.xml
> >> /content/es/file.xml
> >> /content/fr/file.xml
> >>
> >> 3) Workspaces for each language
> >>
> >> /content/file.xml (in 'en' workspace)
> >> /content/file.xml (in 'es' workspace)
> >> /content/file.xml (in 'fr' workspace)
> >>
> >> Other? My ears are open, Thanks in advance.
> >>
> >>
>
>
Re: David's Model and translation projects
Posted by Tobias Bocanegra <to...@day.com>.
hi,
iiuc, data first means, that the data drives the structure and not
that the structure drives the data. eg having a nodetype like this:
[Phrase]
- en (string)
- es (string)
...
beforehand that forces your data into a certain format would be wrong.
imposing a certain hierarchy on your data is ok and natural.
regards, toby
On 9/7/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
> Hello Tobías, thanks for your answer.
>
> Approach #2 is indeed, natural, however the "problem" I see with
> approach #2 is that it seems to break David's rule #1 (data 1st vs.
> structure 1st) by imposing a fixed content structure to projects (for
> example, /common/ /en/ /fr/ /es/ /it/ etc.).
>
> I'm not saying I won't end doing things this way (actually, it is so far
> my personal choice), I just wanted to know if there was a way to do it
> in a way that conforms a bit more to David's rule #1.
>
> Thanks again.
>
> Tobias Bocanegra escribió:
>
> > hi,
> > it certainly depends on your intention, but having a folder for each
> > language is imo the best approach. you might have other resources
> > later (like images) that are language dependent that you can put in
> > the folder.
> >
> > regards, toby
> >
> > On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
> >
> >> Hello there,
> >>
> >> I'm considering David's Model
> >> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering how
> >> would David handle translations of documents.
> >>
> >> Let's say I have a file, for example: file.xml which is written in
> >> English, and I want to store its translation to, say, Spanish. Which
> >> would be the recommended storage model?
> >>
> >> 1) Common storage place
> >>
> >> /content/file.xml (English version)
> >> /content/file-es.xml (Spanish version)
> >> /content/file-fr.xml (French version)
> >>
> >> 2) Folders for each language
> >>
> >> /content/en/file.xml
> >> /content/es/file.xml
> >> /content/fr/file.xml
> >>
> >> 3) Workspaces for each language
> >>
> >> /content/file.xml (in 'en' workspace)
> >> /content/file.xml (in 'es' workspace)
> >> /content/file.xml (in 'fr' workspace)
> >>
> >> Other? My ears are open, Thanks in advance.
> >>
> >>
>
>
Re: David's Model and translation projects
Posted by Fabián Mandelbaum <fm...@gmail.com>.
Hello Tobías, thanks for your answer.
Approach #2 is indeed, natural, however the "problem" I see with
approach #2 is that it seems to break David's rule #1 (data 1st vs.
structure 1st) by imposing a fixed content structure to projects (for
example, /common/ /en/ /fr/ /es/ /it/ etc.).
I'm not saying I won't end doing things this way (actually, it is so far
my personal choice), I just wanted to know if there was a way to do it
in a way that conforms a bit more to David's rule #1.
Thanks again.
Tobias Bocanegra escribió:
> hi,
> it certainly depends on your intention, but having a folder for each
> language is imo the best approach. you might have other resources
> later (like images) that are language dependent that you can put in
> the folder.
>
> regards, toby
>
> On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
>
>> Hello there,
>>
>> I'm considering David's Model
>> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering how
>> would David handle translations of documents.
>>
>> Let's say I have a file, for example: file.xml which is written in
>> English, and I want to store its translation to, say, Spanish. Which
>> would be the recommended storage model?
>>
>> 1) Common storage place
>>
>> /content/file.xml (English version)
>> /content/file-es.xml (Spanish version)
>> /content/file-fr.xml (French version)
>>
>> 2) Folders for each language
>>
>> /content/en/file.xml
>> /content/es/file.xml
>> /content/fr/file.xml
>>
>> 3) Workspaces for each language
>>
>> /content/file.xml (in 'en' workspace)
>> /content/file.xml (in 'es' workspace)
>> /content/file.xml (in 'fr' workspace)
>>
>> Other? My ears are open, Thanks in advance.
>>
>>
Re: David's Model and translation projects
Posted by Tobias Bocanegra <to...@day.com>.
hi,
it certainly depends on your intention, but having a folder for each
language is imo the best approach. you might have other resources
later (like images) that are language dependent that you can put in
the folder.
regards, toby
On 9/6/08, Fabián Mandelbaum <fm...@gmail.com> wrote:
> Hello there,
>
> I'm considering David's Model
> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering how
> would David handle translations of documents.
>
> Let's say I have a file, for example: file.xml which is written in
> English, and I want to store its translation to, say, Spanish. Which
> would be the recommended storage model?
>
> 1) Common storage place
>
> /content/file.xml (English version)
> /content/file-es.xml (Spanish version)
> /content/file-fr.xml (French version)
>
> 2) Folders for each language
>
> /content/en/file.xml
> /content/es/file.xml
> /content/fr/file.xml
>
> 3) Workspaces for each language
>
> /content/file.xml (in 'en' workspace)
> /content/file.xml (in 'es' workspace)
> /content/file.xml (in 'fr' workspace)
>
> Other? My ears are open, Thanks in advance.
>