On 2/24/06, Piotras <pp@info...> wrote:
> > OK. Perhaps we could add a UNIQUE constraint in the table definitions
> > to enforce this. Otherwise we can easily end up with strange errors.
> Can we return DUPLICATE ERR easily then?
Yes, once we have proper database error reporting...
> Not at all. This is very difficult to make two features as one.
> These features are: translation and translated content being translated
> by particular translator. We are far the from second feature so you can not
> create content with lang X if you do not have content with lang 0.
> Basically you always have some lang 0 , it may be English , Russian, etc.
> Then you can start translate content and create lang X "entry".
Ah, now I see it! Thanks.
> > OK. Having the "sitegroup" column in all tables is quite nice for some
> > operations even though it isn't required and can even cause
> > inconsistencies due to the non-normalized table structure it creates.
> > I'd suggest always having the column and mandating that the MultiLang
> > sitegroup always be the same as the main object sitegroup, even at the
> > expense of potential problems.
> OK, but ML content is not accessible by any API or internal function as standalone
The sitegroup column is good for things like indexing and table
clustering that do not need to be reflected in the API.
> In practice you have few languages available on website so replicating all lang
> content shouldn't be so difficult.