ALL!! of the language variables in a lang file

While translating content manager into my native Russian I found several language issues that were not actually variables (guess somebody just missed them). For example ’After saving’ phrase is not in english.inc.php - it is scattered over a dozen of documents in ’dynamic’ dir. Almost the same with the whole ’Site schedule’ section. Now if I wish to provide a really COMPLETE localization - I will need to include that dozen of files along with russian.inc.php. And that is complicating.

Thanks.

I would agree with you...however, keep in mind that it’s difficult for plugin, module, and snippet developers to edit the language files everytime they create an update. What I would like to see in the future is for the language files to be transfered to the database in their own table. That way, updates to the language variables can be made relatively easily and be managed right from within the manager. Plus, an installer for a plugin, module, and/or snippet could be implemented that would allow for adding, modifying, and/or deleting entries that relate to a give plugin, etc.

About language files, there was a discussion about it. I don’t know what decision was selected. rtrash can give you more informations. I know that there was some discussion about putting files of language in the repertory of the resources.

I think an installer is good idea but it is not yet easy to configure it for developers. A plugin on modxcms to create package and to configure the installer will be useful. I think of that since a moment. I will interesting to code this but I do not have enough informations (I believe that a new installer is envisaged ?)

Here’s another idea regarding putting the language files into the database. Each language setting could effectively be tagged with a field that distinguishes its use. For instance, any MODx related language settings could be tagged as "modx" while something like the TinyMCE language settings could be tagged as "tinymce". This way when developers create their own installers they can have them lookup the current language settings for a specific plugin or module and change them. So, within a single table, the language settings could be broken down by setting name, value, language, purpose/use, and whatever else we need to allow for the filtering of the languages. Also, if performance is a concern due to the language settings being in the database think about this...the language files are primarily used within the manager the majority of the time and thus would not pose any serious performance issues for the front-end of a website. However, if language settings are used on the front-end, I’m sure there’s a way we can get the language settings to be cached much in the same manner as the pages. Hmm...lots to think about!

I think also that database to store language settings is a good idea for performance.
But I don’t understand well how you suggest to store data : only with one table for all languages or with one table by language ?
I prefer the second solution beacause it will be hard to maintain translation.

About the cache, it will be possible to modify Modx easly to cache pages by languages ? For a next release of course