Localisation

Hello

We had this issue earlier this year here. I would like to ask, if the possibility to add a non-english UI for the admin soon?

cheers

Hi Martin, we have started to work on our 5 big ticket items:

  1. Multi-Site
  2. i18n
  3. REST
  4. Custom Content Types
  5. Content Regions

hopefully soon.

signature0.jpg

Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

It is still on our list of items to tackle, but it is a significant change that hasn’t been requested as often as multi-site or custom content types. As always, we are open to:

  1. Community help
  2. Sponsorship of the feature
    Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Also, on this thought-- I should add that localization comes in two fronts:

  1. Admin

  2. Front-end site
    And I would break front-end down into two categories

  3. Static stuff used in layouts

  4. Content (pages, entries)
    In regards to front-end content, I know there’s been talk of creating multiple content records–one per language. I’m not a huge fan of that since I only want to have one slug, etc for a piece of content, and I don’t want to have to duplicate all my markup, images, widgets for each of the languages when only the text is different.

After thinking about this for a bit-- what if we attacked it like so:

  • Each ContentBox app would have 3 resource bundles
    • System – Used in admin.
    • Site – Used by the site layout for any static bits of text in header, footer, nav, etc.
    • Content – This would be requested via a content ID and would hold text specific to that piece of content.
  • The Site and System resource bundles would have a “module” namespace in them for any internationalized modules that wanted to have output in the admin or site respectively
  • Modules could also overwrite the base keys or register a new language in order to add/modify additional languages to the front-end or admin via dropping modules.
  • This would allow you to create a "talk like a pirate module that would make your site talk like a pirate on National Talk Like A Pirate Day :slight_smile: (September 19)
  • The Content resource bundle would be editable on the content edit page. That way, if you have a blog entry with a title, subtitle, excerpt, 3 paragraphs, and some alternate ext for the images, you could create a handful of keys JUST for that piece of content and include them right there when editing the record. All languages would share the same content record, HTML, custom fields, layout settings, etc.
  • Add a CKEditor plugin in the edit content page to jump straight to editing a bit of text in the resource bundle.
  • Perhaps even have a drop down above the editor and select a language and edit the text right inside a box in the editor, but on save the actual text would be placed in the content resource bundle and only the placeholder would be saved.
  • Add an interface in the admin edit the System and Site bundles with import/export functions
  • Include some CBHelper methods
    • to get a key from a specific bundle/contentID
    • render a drop down of the registered system or site languages

If we wanted to move in this direction, we could add core support for the resource bundles (including CBHelper additions and admin screen to edit). Then, people could work together on replacing the actual text in our admin and default layouts to use the RB keys as well. Once that’s done (or during I guess) people who wanted to help offer other translations could work on adding new languages. The languages we wanted to add to the core, they could submit an export of their Site and/or System resource bundles. Any others could be wrapped up in modules and placed on ForgeBox. This could help offload some of the work to the community members who want to help while still keeping it tied to the core.

Thoughts?

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Great!

I will contribute the german translations for sure. My french and italian knowledge ist limited, good enough for ordering food and drinks, but not good enough for a localisation.

I think, it would be great to have the core functionality out of the box already translated in some languages. This would be give a great impression to future customers.

Please don’t forget, that foreign languages are needing more space in any dialogs and buttons;-) Especially french have sometimes really long words.

@Luis: Please keep me up-to-date, when i can start with the german stuff.

My girlfriend is actually adding articles for her company using ContentBox. I tried to translate “slug” to german, which wasn’t easy. I’m still searching for the right word.

cheers

I second that…pls guys… without multilingual admin section we can contenbox use only in exceptional cases in european customer projects - at least outside the UK.

Get me on the list of people who like to support it.

I provide any help possible…translations (German), thinking, coding, etc

Daniel

To help understand where the need is, are you looking for a multi-lingual support in the admin or for the content/front end, or both?

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

I think both is needed. I think front end would mainly mean related content in backend (link all language versions, overview where translated content is missing)

Yes, I understand both are needed, I’m just trying to help determine which one people need more if we have to choose on over the other to start on :slight_smile:

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

For us, the localized Admin UI is our #1 feature request in general. No german UI, no customers. Simple like this.

Putting all the admin stuff to resource bundle files will be a lot of work but I think it will not need much programming. This could be done with community help.

I’m not too sure about related content, this will need the right concept. Especially with the blog since there is currently only one blog (We have solved it with categories for each language which are hidden for the user, e.g. on German site only posts with category DE are shown)

I would start with multi lingual admin (local time and number formats are needed as well)

Thanks for the input. I am meeting with Luis this whole week and we are talking about all the many projects on our horizon and which ones we tackle first. This is definitely on our list. We have amazing stuff planned for ContentBox but one of my goals is to find the biggest items keeping people from adopting it right now,

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Thanks for additional insight Gunnar. I agree this would be a good project to get community help with.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

I’m suggesting to tie the Resource Bundles either to views or handlers. Each view or handler should load automatically the related resource bundle and resource bundles should be kept in a mirrored folder structure. What do you think?

I haven’t localized too many sites, but I’ve always just had a single resource bundle for the whole site and then simply organized the strings inside the bundle using the dot-delimited paths.

Ex.
admin.dashboard.title
admin.dashboard.updates
admin.dashboard.settings
admin.content.title
admin.content.instructions
admin.content.buttons.edit
admin.content.buttons.delete
admin.content.editPage.title
admin.content.editPage.labels.slug
admin.content.editPage.labels.title
admin.content.editPage.labels.excerpt

If you use the resource bundle editor in Eclipse, it lets you collapse everything down as a tree so managing a thousands of keys isn’t hard as long as they are organized nicely. It also lets me share site-wide strings such as “submit” or “cancel” once.

That being said, I think we’d probably store the resource bundles in the database for ContentBox, so file structure and editors would be sort of moot.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Please let me known, when i can start adding german strings to the UI.

I think it will be easier to get others involved if we have multiple files. So a part could be done by person a and the other by b.

I’m wondering how to do localization für Coldbox, e.g. ValidationManager? I think it needs to be done as well otherweise you get English messages in a localized interface.

The validation has i18n support though.

I haven’t localized too many sites, but I’ve always just had a single resource bundle for the whole site and then simply organized the strings inside the bundle using the dot-delimited paths

I did a lot of translations in the past for different applications, One resource bundle for the admin UI would be the simplest.

Are you interested to see some samples from other applications?