multi-lingual websites

[Chris]

Hey everyone,
I've been experiencing problems with multi-lingual features, and have
seen several people struggling with the same problems in the forums.
it would be nice to have better multi-lingual support in general, and
i wanted to point out a few issues ive seen. I really like the
architecture and the concept of Translatable, unique url's and
translation_groups, but the cms seems to be lacking some important
features for multi-lingual sites.

Translating Dataobjects through a ComplexTablefield has been broken
for over a year and pretty much anyone that needs to use it has had to
apply a patch in ticket #4199. To the best of my knowledge it doesnt
depend on session variables anymore, and i added a patch today to get
it to work with 2.4.5. I am upgrading a multi-lingual website from
2.3.3 to 2.4.5 and i put off these security updates because of the
hacked upgrade process. i know others share the same predicament.

Dataobjects dont take advantage of Translation Groups either, and with
the exception of using translatable modeladmin, theres no way to
translate dataobjects.

Pointing domains at translated sections of the site is also weird, and
theres no great example of how it should be set up. i figured out a
way to do it by modifying the .htaccess and writing page_controller
rules, but the fact that /home redirects to / made it a little more
challenging, and i'm not entirely sure if there is a better solution.

I've read a little about the initiatives for Silverstripe 3.0, and
wanted to voice the problems that have came up and hopefully they can
be considered in the new 3.0 design.

Thanks,
-Chris

[Ingo Schommer]

Hey Chris,

Thanks for raising this! I think its a typical case of "scratch your own itch",

and most of the client projects the core devs are working do

not need multilingual features, hence it didn't get a lot of attention.

Its currently not on our radar for SilverStripe 3, although

we're always happy to accept contributions - and the ticket you

mentioned is a good start in this.

I think we need a bit of clarification and discussion how controllers

should interact with varying model behaviour - the patches all

solve very specific problems, but also add more coupling

throughout core. Translatable in already much too coupled

to CMSMain, Versioned, SearchForm etc. - I'd rather see clean decoration/

extension points, such as FormField->Link() could be decorated

via a TranslatableFormField. Perhaps even to an extent where

Translatable can become a module of its own - fork with a feature branch, anyone?

In terms of managing translatable DataObjects via CTF

and other interfaces, I can't see any change to the UI in the patches -

how is that handled in ModelAdmin etc?

Ingo

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

---

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

in...@silverstripe.com

Phone: +64 4 978 7330 x 42

Skype: chillu23

[Chris]

Hey Ingo,
thanks for the reply. I wasnt sure where Silverstripe has been going
with Translatable, as it is fairly coupled with CMSMain, etc, but no
real improvements after 2.3.2, so i appreciate the honest response. I
can see it becoming a module and decoupling from the core as well.
I'm assuming you'd keep i18n in the trunk and decouple Translatable,
then create extensions and decorators for Form, SearchForm, etc,
correct? (you still want a non-translatable site to have a selectable
default language).

the patches submitted in ticket 4199 only fix the ctf, and dont
provide any interface to translate dataobjects. although the patches
tie translatable to the core a little more, translatable is already
tied to the core and it would fix something that has been broken for a
long time. For anyone that is just entering the multi-lingual arena,
this will be a much less frustrating situation for them as it would
make the default install of silverstripe work correctly without
patches. in the meantime i'm happy to lend a hand in constructing the
multi-lingual module.

To answer your modelAdmin question, currently the only way dataobjects
can be translated is with Sam's TranslatableModelAdmin module. it is
a modelAdmin that lets users create & translate dataobjects to allowed
locales. i do see where this falls short though.. aside from a few
bugs, it is easy for translated dataobjects to loose their association
with pages. Anyone that creates a CTF on a normal page and uses a
filter 'where parentID = {$this->parentID}' will not see a choice to
of DataObjects to add since TranslatableModelAdmin doesnt check the
original page's translation group for possible parents. i also have
issues with modeladmin, but could see some interface extending
LeftAndMain for a little more specialized operation

the other thing i would consider in the Pages / SiteTree section is to
streamline the translation of pages and their associated DataObjects.
when a user translates a page, look at its dataobjects (if they arent
translated yet) create translated dataobjects (probably should be
staged) and add the translations to the translation_group. this would
be helpful when a customer says 'lets add a 7th language' as right now
i need to create a new dataobject for each one manually. beyond that,
maybe add a translation section of the popup to translate individual
dataobjects to each locale.

I also know that when translating text, different people will
interpret the translation differently. In larger companies, its not
uncommon for the translation to be changed a few times. A versioned
dataobject interface could also lend to ideas for what the translation
interface could look like too. Ultimately its nice to be able to do
as much as you can inline while in the pages section of the CMS, but
it may be a bit like the image uploader in the pages section.. very
handy to have, but some things are better or easier done in files &
images.

I guess i am a little confused about what the silverstripe 3.0 ui will
look like. is it going in the direction of concrete-5's admin ui? I
thought i read Felipe saying that the best admin interface is 'no
interface' meaning a front-end system, where someone else commented
that they are happy that silverstripe will keep a backend interface,
which i think means youre keeping the sitetree / pages pane. the
reason why i bring this up is that a new UI can impact translatable,
and provide more possibilities for a translation UI.

thanks again,
-Chris

[smurkas]

Just like Chris I have a rather vested interest in getting
Translatable in working order. I do multi-lingual web sites regularly
and having to manually patch/edit the core every time is getting very
old. For me it would be giant step forward just to get one of these
patches for Translatable in so it actually works, nevermind the
coupling etc. right now. In the long term I would love to help build
the new Translatable module but I think we'd need guidance from
someone on the core team if we're going to build something that
actually holds up.

I'm all for Chris suggestion of just getting that patch in so the
basics work. After that we can have a look at stuff like having to set
i18n to the same locale as Translatable in order for entity
translations in the frontend to work properly etc.

[Ingo Schommer]

Hey Chris,

On 14/02/2011, at 6:29 PM, Chris wrote:

> Hey Ingo,
> thanks for the reply. I wasnt sure where Silverstripe has been going
> with Translatable, as it is fairly coupled with CMSMain, etc, but no
> real improvements after 2.3.2, so i appreciate the honest response. I
> can see it becoming a module and decoupling from the core as well.
> I'm assuming you'd keep i18n in the trunk and decouple Translatable,
> then create extensions and decorators for Form, SearchForm, etc,
> correct? (you still want a non-translatable site to have a selectable
> default language).

Yes, i18n is a part of core (the CMS itself is translated),
Translatable for database-driven translations can be a module.

>
> the patches submitted in ticket 4199 only fix the ctf, and dont
> provide any interface to translate dataobjects. although the patches
> tie translatable to the core a little more, translatable is already
> tied to the core and it would fix something that has been broken for a
> long time. For anyone that is just entering the multi-lingual arena,
> this will be a much less frustrating situation for them as it would
> make the default install of silverstripe work correctly without
> patches. in the meantime i'm happy to lend a hand in constructing the
> multi-lingual module.

The thing is that we need somebody to drive this process - the core
team will be very busy with stuff that *is* actually on the roadmap
in the next months, and can help out with advice at most :)
I'd suggest you branch off sapphire and cms,
and create a new "silverstripe-translatable" module
where we successively merge features into, in parallel
with removing them from sapphire and cms.
This will require the creation of new decorator callbacks.

>
> To answer your modelAdmin question, currently the only way dataobjects
> can be translated is with Sam's TranslatableModelAdmin module. it is
> a modelAdmin that lets users create & translate dataobjects to allowed
> locales. i do see where this falls short though.. aside from a few
> bugs, it is easy for translated dataobjects to loose their association
> with pages. Anyone that creates a CTF on a normal page and uses a
> filter 'where parentID = {$this->parentID}' will not see a choice to
> of DataObjects to add since TranslatableModelAdmin doesnt check the
> original page's translation group for possible parents. i also have
> issues with modeladmin, but could see some interface extending
> LeftAndMain for a little more specialized operation

Having this code in a module will make it easier to package
less stable features like translatablemodeladmin in the same codebase,
providing a better dev experience (we have to more conservative
with getting stuff into core).

>
> the other thing i would consider in the Pages / SiteTree section is to
> streamline the translation of pages and their associated DataObjects.
> when a user translates a page, look at its dataobjects (if they arent
> translated yet) create translated dataobjects (probably should be
> staged) and add the translations to the translation_group. this would
> be helpful when a customer says 'lets add a 7th language' as right now
> i need to create a new dataobject for each one manually. beyond that,
> maybe add a translation section of the popup to translate individual
> dataobjects to each locale.

Thats very use case specific, and would have to be defined
on a relation-level. Should be possible with relationship getter
overloading already, maybe its just a recipe?
The new ORM in SilverStripe 3, and work going into versioning
of relationships will likely have benefits for Translatable as well.

>
> I guess i am a little confused about what the silverstripe 3.0 ui will
> look like. is it going in the direction of concrete-5's admin ui? I
> thought i read Felipe saying that the best admin interface is 'no
> interface' meaning a front-end system, where someone else commented
> that they are happy that silverstripe will keep a backend interface,
> which i think means youre keeping the sitetree / pages pane. the
> reason why i bring this up is that a new UI can impact translatable,
> and provide more possibilities for a translation UI.

The UI won't drastically change for 3.0, incremental improvements
rather than revolution :)

[Chris]

Thanks Ingo,
I completely agree that having a separate module will make it easier
to maintain both.

I'd be interested in starting the multi-lingual feature branch, but
wont be able to start the project for a few months. in the meantime
if anyone else wants to get started sooner, I dont want to hold anyone
back and I can jump in when i get time.

what is suggested for roadmap & bug tracking? I use mantis here but
thats more of a private system.
thanks again for the insight.
-Chris

[Ingo Schommer]

Hey Chris, for bugtracking in your feature branch and module repo I'd use github.

If the feature branch has (minor) bugs remaining by the time we merge back,

we can migrate these over to open.silverstripe.org.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.