After installing “SuperMenu” and checking out other modules, i realized that the modules are not prepared for any localisation. This would give a funny mix, if the backend would be translated e.g to german and modules are not capable for translation. So, i18n should enter into the playground, right? In general, text and code should be seperated anyway.
Maybe it’s time to establish guidelines and approval procedures for 3rd party code??
Cheers.
Hi Martin–
I have to disagree to some extent. While I am all for guidelines, best practices, etc., I think an approval process would be pretty tough to manage. Especially for free, open source modules, widgets, etc. If we were talking about addons for purchase, perhaps, but otherwise I think an approach like the WordPress plugin repo is the only way to go. Sure, you get a mixed bag, but you also get (potentially) more options.
Re: SuperMenu, I welcome any and all suggestions you might have for making it better, more extensible, compatible with i18n concerns, etc. Also, the code is freely available on GitHub, so you can always contribute ideas there, or even fork it and push changes to make it better.
Thanks!
We’ll, I doubt we’re going to start rejecting 3rd party modules because they don’t support internationalization. That would be an excellent goal though. I would recommend contacting the module maintainer and asking if they’ll help internationalize them. Most of the modules are located on GitHub where you can form and submit pull requests to the owner. One think I’m not sure on is how it would all work. I assume each module would need to have it’s own resource bundle. Then I suppose we’d need a convention for where the current language is stored in the core modules so the 3rd party module could pick it up.
I know there’s no official support for have several translations of your content on the front end (save building your site hierarchy again for each language) and I don’t think we’ve added i18n for the admin either. This is probably something we’d love to have help on since we’re re-envisioning the admin interface right now. There’s so many good projects like this to take on and we’re counting on community support to help them get done.
Richard M is leading the charge to help reskin the admin site right now. Richard, have you given any thought towards extracting out all the text as we go? This may not be a bad time to think about that.
Thanks!
~Brad
Yes the UI change needs to involve i18n hand in hand. We already added capabilities via databoss and will apply it to this once we start. I will also update the ColdBox i18n capabilities to allow multiple resource bundles and also module bundles.
Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano
Hello,
Maybe i used the wrong word. “Approval” was ment more as “Guidance”. It would be great, if modules where ready for localisation and the people who wants the strings in their language would contribute this. I made the expeirence, that US-based programmers simply forget, that the english language is not spoken on every spot on this planet.
We live in small country and we habe 3 major language zones here: German, french and italian. We made the experience, that if a software is not localized, a lot of users will not accept it.
Regarding the i18n for the backend: I will contribute the german strings as soon as you are ready. I also can help translate some modules.
Cheers.
I hadn’t given thought to localisation of the admin at this stage, but it does seem like an excellent opportunity to work it in with the rest of the changes.
Richard
Perfect. I will meet with you Richard to go over things. Actually I am thinking for ContentBox to localize in the db and not in resource bundles. Also adding a simple manager interface for this so users can update their languages or add more on te fly.
Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions
I prefer resource bundles in terms of organisation and exchanging.
Exchanging files are much more simpler for the community (github) rather than database records. It also would easier to copy translations between actual projects.
To change the language, i see different solutions: Use the browser language and a dropdown box to choose or overrule the actual language, which will be stored in a cookie.
If a certain language resource of add-on is not available, english will be the fallback language anyway.
It might be tricky, if the backend has several localisation loaded and a module is only available in english. This would be babylonian thing 
I’m sure, that if let’s says a german speaking guy writes a module, he will start in english anyway and will contribute the german language set later on. I don’t think that a swahili only version of a module will hit the donwload area
Personally I love the idea of being able to install a language pack as a module. Then just distribute the default language modules with the build. With the others available on forgebox.