From: Casey J. <cas...@jo...> - 2012-04-21 18:08:59
|
We also used option 2 for managing multi-lingual DITA content. The only drawback is that managing parallel trees means that if you are moving/renaming documents in the database there needs to be a trigger to do the same operation to the other trees. On Sat, Apr 21, 2012 at 6:54 AM, Paolo Di Pietro <pdi...@di...>wrote: > Hi Stéphan, > > I faced the same question a couple of years ago. Now I'm using not only > multilingual, but also multialphabet ad rtl's. > > I prefer the option 2 for the following reasons: > > a) as I'm using rdf, this is the standard way to describe things inside > an rdf:Description > b) maybe, you avoid to duplicate other data if your collection doesn't > contains only that one Doc > c) an eventual browser should be able to automatically detect the user > language and display only using the current language (this should run > just now, but, in my experience, the browsers semmes not to respect > this spec). You will be ready for the future > > Paolo > > Il 20/04/2012 10:53, "Stéphane S." ha scritto: > > Hi, > > > > I would like to manage multilingual resources in a web application done > with eXist and I am seeking for an advice on how to organize the database > resources and collections, please apologize me if this list is the wrong > place for such discussions. > > > > Basically, if there is a resource "mydoc.xml" inside a collection > /db/data containing a<Doc>...</Doc> to be stored in two languages, I see > two options : > > > > Option 1 : create a single resource with two "forks" under a common root > (e.g. AnyLanguage) > > > > <AnyLanguage> > > <Doc xml:lang="en">...</Doc> > > <Doc xml:lang="fr">...</Doc> > > </AnyLanguage> > > > > Option 2: create two collections (en and fr) and store two documents > (this also applies to full hierarchies of multilingual resources) > > > > collection /db/data/en contains mydoc.xml that contains<Doc > xml:lang="en">...</Doc> > > collection /db/data/fr contains mydoc.xml that contains<Doc > xml:lang="fr">...</Doc> > > > > Simply considering querying data, I guess with option 1 one would have > to write : > > > > let $lang := 'en' > > return collection('/db/data')/AnyLanguage/Doc[@xml:lang = > $lang]//{my-path-expression} > > > > whereas using option 2 that would be something like: > > > > let $lang := 'en' > > return collection(concat('/db/data/', $lang)//{my-path-expression} > > > > I am wondering if there are some hidden drawbacks in using one option or > the other (performance, sustainability, etc.) ? > > > > Can anybody with experience in this regards could give me an advice ? > How do you manage this in your applications ? > > > > Thanks in advance, > > > > Stéphane S. > > --- > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > For Developers, A Lot Can Happen In A Second. > > Boundary is the first to Know...and Tell You. > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > > Exist-open mailing list > > Exi...@li... > > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > -- -- Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you. |