1
-----------------------------------------------------------
I have used smarty in another CMS and made an "article call other article": a smarty template to pick the right text from available alternatives based on user parameters.
This way we can store the different version as a new article and have them evaluated to find the linking code.
For example:
Suppose there's a forum and you post in english. All is normal but for the language field. However the script stores the message in two parts:
1. A database entry with the actual message but stored in a special category that matches the language selection.
2. An extra entry located in the proper category (that the user browse) which store the smarty code with references to the entries of the different languages.
Basically it just takes some php code to be adapted to any module calling this kind of text and can be used not only for languages but for anything with version selection.
I call it "bridge component" and may take parameters from custom variables like user level or shopping cart items.
-----------------------------------------------------------
I think we dont need a new core release for this, just a set of basic modules. To have full multilingual the core pack should came with all these features (as i review):
- Message tools
1. the "bridge", component to be included in the modules.
it uses smarty functions to fill variables as need.
2. basic smarty templates for the modules using it.
like articles, news, forum, catalogs, etc.
- Site tools (these are important!)
3. a module to edit the translation texts. there are preferences in the admins areas that can be named here.
this avoids having custom symbols that dont match every language files and also provide default values.
4. redo the default themes to change "images/icons" to "images/languages/icons" with every image url in the templates in the core and in the modules. provide the variable to fill in the language in custom themes. this can be combined with additional translation texts.
- To select the language
5. the selector module, set as language selector for the users.
6. the same selector module but generic, in the admin areas, that pass variables to the "bridge" component.
-----------------------------------------------------------
The module that does "machine translation" should not be included in the core pack.
Custom modules and templates should still be done by the webmasters since these reflect the site needs or business.
Hope these ideas help to speed up the multilanguage development as possible.
I have used smarty in another CMS and made an "article call other article": a smarty template to pick the right text from available alternatives based on user parameters.
This way we can store the different version as a new article and have them evaluated to find the linking code.
For example:
Suppose there's a forum and you post in english. All is normal but for the language field. However the script stores the message in two parts:
1. A database entry with the actual message but stored in a special category that matches the language selection.
2. An extra entry located in the proper category (that the user browse) which store the smarty code with references to the entries of the different languages.
Basically it just takes some php code to be adapted to any module calling this kind of text and can be used not only for languages but for anything with version selection.
I call it "bridge component" and may take parameters from custom variables like user level or shopping cart items.
-----------------------------------------------------------
I think we dont need a new core release for this, just a set of basic modules. To have full multilingual the core pack should came with all these features (as i review):
- Message tools
1. the "bridge", component to be included in the modules.
it uses smarty functions to fill variables as need.
2. basic smarty templates for the modules using it.
like articles, news, forum, catalogs, etc.
- Site tools (these are important!)
3. a module to edit the translation texts. there are preferences in the admins areas that can be named here.
this avoids having custom symbols that dont match every language files and also provide default values.
4. redo the default themes to change "images/icons" to "images/languages/icons" with every image url in the templates in the core and in the modules. provide the variable to fill in the language in custom themes. this can be combined with additional translation texts.
- To select the language
5. the selector module, set as language selector for the users.
6. the same selector module but generic, in the admin areas, that pass variables to the "bridge" component.
-----------------------------------------------------------
The module that does "machine translation" should not be included in the core pack.
Custom modules and templates should still be done by the webmasters since these reflect the site needs or business.
Hope these ideas help to speed up the multilanguage development as possible.
