I'd say, you'd want to avoid using class names to determine language choice.
There are two types of text. Content (user input or application data) and application text (text added by the programmer). From my experience, the application text is usually centralized in a single class. So, if "medicine" as a term is being used in the application (added by the programmer), but the German version is needed, then there would be an extra query to call up the translation for the term "medicine". Now, with content about the medicine, like the name of a specific medicine or other properties of a particular medicine, then I'd put the translations in separate documents for each medicine. This could also be handled well over a "language" edge, which links medicine documents to other translated medicine documents. This would allow, for instance, to go from German to English and vice versa, if needed. If you don't need this, then I'd just have a language property in each document and filter on that property. Scott -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
