17488 Posts in 4473 Topics by 1978 members
|Go to End||Next >|
Google Summer of Code Hacker
20 July 2007 at 10:00am
I'm currently working on adding the ability to have a certain content in more than one language. In this way we can for example visit a page and this will be displayed depending on our browser language.
So an important point here it's how to manage this translations. My idea is to separate the site content tree depending on languages, so you can switch easily and work with the desired language tree. If you are translating a content, you will see the same tabs and fields that when writing new content, but duplicated (so you can see the original values).
There is also a new Translations tab where you can set in which language the original content is written in, kick off new translations of that content or add new languages to the site.
A picture is worth a thousand words, so I've attached some screenshots to reflect this idea. Any comments or suggestions will be appreciated
Core Development Team
20 July 2007 at 1:51pm
I like where you are going with this. One change I think is important would be placing the language fields side by side, as opposed to being above and below each other - it makes much better use of the screen real estate and makes comparisons easier.
Would be interested to get your feed back on the attached mock-up.
20 July 2007 at 2:33pm
sweet, thanks for your post bernat!
the "translations"-tab contains mostly global settings, but its positioning inside the specific page implies a page-specific setting. (e.g. can i set the default language on a page-by-page basis?). the lack of a global settings UI is a generic silverstripe problem. tim/bernat, do you have any thoughts on this? doesnt necessarily have to be resolved now, just wanted to point this out as a usability issue.
i dont think we need an interface for adding a new "site language", in the rare case you come up with something like "klingon language" that we havent covered in the dropdown, we should have some _config.php-setting instead. otherwise we need a separate database table to store newly created site specific languages, which confuses more than its worth.
@tim: putting fields side-by-side requires a higher screen resolution, especially when working with more complex fields like multi-column tables - users might end up having to scroll even on 1280 res to compare original with translation. also, it poses quite a challenge in terms of CSS-layout (silverstripers might remember how we struggled with the same problem in the "inform fact finder"): e.g. if the field label of the translation is omitted, it is very hard to keep fields aligned, because we're using linear divs rather than table-rows.
its probably a good idea to somehow mark the framed original fields as showing the "default language", as not to confuse users which field actually contains the translation (and is editable).
i'd also prefer a way to set the currently edited language outside of the translation-tab, as its more a "global switch" that wouldnt be expected in the tab. tim proposed a setting in the (always present) editor toolbar. alternatively could be laid out like the "page view" tabs below.
20 July 2007 at 2:59pm Last edited: 20 July 2007 4:59pm
btw, heres the link to tims UI proposal:
Google Summer of Code Hacker
21 July 2007 at 12:36am Last edited: 21 July 2007 4:07am
The "original content language" isn't the global default language but the language that the current page is in. Placing it in the editor toolbar looks great
About the "add site language" thing, its purpose is to avoid an exhaustive list of possible languages to start a new translation. A common multilingual site may use a few languages, so if they previously define them they'll be able to use a more customized dropdown when setting the language of a new translation (we could offer the exhaustive list when they are adding these languages though).
As you said this would be better in a global settings/preferences UI, but it's also handy if it's near the list of languages (if somebody wants to add a translation in a language that has not been used yet, he can easily add this language).
I'm opening a new thread to discuss the possible preferences/settings UI. (edit: link http://www.silverstripe.com/google-summer-of-code-forum/flat/2767)
23 August 2007 at 3:34am
Sorry to intrude here as a non-SoC-er and non-committer.
Still, if you could give an approximate ETA for this feature, I would be very grateful.
If you delete my post and just send me the info otherwise, I'm just as happy.
I am evaluating CMSs right now for an organisation I am working for for a year, and since we're Quebecois, multilingual content support is critical (as in, we must have it by law and maintaining separate sites is too much of a bother).
Other than the lack for multi-language content support, I like Silverstripe best (with a wide margin) so far, but without this feature, I can't really get it into consideration.
23 August 2007 at 5:44am
we're currently finishing the GSoC-i18n-project (deadline: 31/08),
and we're aiming to have a useable API for translating static and database-content in the gsoc-branch. afaik, silverstripe is planning to integrate all gsoc-work into the 2.1 release, which doesn't have a release-date yet.
please keep an eye on:
http://doc.silverstripe.com/doku.php?id=daily-builds (deadlines out of date)
http://doc.silverstripe.com/doku.php?id=releases (deadlines out of date)
23 August 2007 at 8:26am Last edited: 23 August 2007 8:27am
Thanks for the info and the URLs.
Also, and this is a bit off-topic, is there something akin to a "reader's guide" for SilverStripe?
I've tried diving into the code for this and some other issues of mine (cf Bugs subforum), and it seems pretty clean, but I last saw PHP around version 3 and after a few years with Ruby, Perl, C &c it's a bit of a culture shock.
I could start at index.php, but at far more than 100k lines, that'll take forever...
|Go to Top||Next >|