> Hi,

Hi,

>> > 4) Are duplicate (sid, lang) values allowed in MultiLang tables?
>> No. If exist , it means bug.
>
> 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?

>> > 5) Does a MultiLang object always have a lang 0 record?
>> Always. ( Like Chuck Norris. :)
>
> Even if I create an object explicitly in some specific language? Do
> the multilang properties then get duplicated to lang 0? This kind of
> makes sense from a technical point of view, but can easily surprise a
> content editor.

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".

>> > 6) Do all MultiLang tables use the "sitegroup" column?
>> Yes. But it's not mandatory IMO.
>
> 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
record.

>> > 8) Can different language versions of an object have different parameters?
>> If you think about higher level API then there are parameters. The same like
>> objects.
>> If you change lang they can be different. Parameters are multilanged so it's hard
>> to say about different parameters for different versions.
>
> OK, so SELECT * FROM record_extension WHERE tablename LIKE '%_i'
> should always return zero rows. The same would apply to the blobs
> table.
>
> MultiLanged parameter handling raises a few other questions. Consider
> an object X with MultiLang records L0 and Ln (for lang n), and
> MultiLanged parameters P0 and Pn (both with the same domain and name):
>
> 8a) If mgd_get_lang() is n and Pn does not exist, is P0 accessible?

Yes, IIRC. It was MidCOM optimized last year.
Every object is qeuried from db with lang 0 if lang n doesn't exists.

> 8b) If Pn exists, is P0 required to exist?

That should be fatal error. You can not translate P0 to Pn while P0 doesn't exists.

> 8c) If not, and if mgd_get_lang() is 0 and P0 does not exist, is Pn accessible?

No.

> 8d) If mgd_get_lang() is n and Ln does not exist, is Pn accessible?

In theory yes.

> 8e) If mgd_get_lang() is n and Ln does not exist, is P0 accessible?

Yes.

> The same questions apply also to attachments, but I suppose the
> answers are the same as the data model is similar.

"As long as you want to implement multilang feature for parameters and attachments
and those are not yet in proposal state for Midgard2" :)

>> > 13) Do the MultiLang _i records have their own metadata fields?
>> No, because this is "part"  of an object. Not object itself.
>
> OK. So if edit the English title of an article, the Finnish version of
> the article is also marked as edited?

That is very good question which I asked myself when I made quota for MgdSchema.

> I'd actually be quite happy if the multilang records had their own
> metadata just like they have their own guids. I'm currently using the
> repligard.changed timestamp in Exorcist to track the last modification
> time of the MultiLang records.

I fully understand the problem. But as I said , ML feature should be optimized
( in current state ) as translation feature. Not really mutlinag content edited by
international team. This is impossible to make with this what we have in Midgard.

In practice you have few languages available on website so replicating all lang
content shouldn't be so difficult.

Piotras



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@midg...
For additional commands, e-mail: dev-help@midg...