Alex, GT staff!

The Form Display DB property of Category table, should be Links::language based, because this property contains the text which is displayed near forms! This text should be in the language of the website, so should be in language.txt of each template dir. This way displayed form names could be different for each language template.
Also Form Values, Column Values, and Default DB property should be should be Links::language based in the same way as I described above.

EDIT: The same problems are true for the Links table, Users table, Reviews table, too.

I think, the situation is very clear.
This should be corrected ASAP.

Until this is not corrected, it is not possible to correctly create multi-language LSQL website, where each language it displayed through separate templates.

Alex, waiting your answer, if you aggree the need of this correction...

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

As far as I can see the Form Display and the Form Values fields are meant to be used only internally, i.e. by the admin. So it does not really make sense to put the values of these fields into the template language files.

Of course things are different if you want to produce the form elements on the user side automatically, based on the data of the admin side. Then you run into the problem you have.

I don't think that your idea can be implemented very easily, and I don't think it will be implemented either.

What you can always do is to define your own language vars, e.g. TABLE_LINKS_URL_DISPLAY, TABLE_LINKS_URL_VALUES etc etc and then in your plugin, you check if these language vars are there, if not fall back on the admin values.

Ivan
-----
Iyengar Yoga Resources / GT Plugins

Yogi,
Yes, you are right, the problem appears when the forms are generated automatically. But generating forms automatically is the logical way. I hate hard coded things in templates... They are not reusable.

I do generate forms automatically in my Xtended Add.Modify.Delete plugin, and I use system modules to do generate forms automatically (GT::SQL::Display::HTML and GT::SQL::Display::HTML::Table).
It is undocumented, but it can generate the form automatically, if you know how to use it.

Yes, your suggestion is valid to use my own variables. But this will mean, that the feature will be only available through my plugin.
I think this is great thing, because my plugin would be very useful for a lot international users . But if I implement this feature and later Alex also implements it, then I made a lot unnecessary work...

Anyway I will be glad, if the users will like my plugin, because it will have such special features what are missing from LSQL, but I would not want to do unnecessary developments.

If Alex says, he want to implement it in next release, then I will work on implementing the other features I want.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...