What do you think? - Multilanguage Backend

[santscho]

What do you think? Would Oliver be shocked, when I would post my wish as feature request? In my point of view, this would be more important than the user management.

phpwcms offers additional fields in the page details and article header, when the language array in conf.inc.php is more than one. Eg. 'de' 'fr' 'en'. Could look like this:


The default language accords to the default language entry in the conf.inc.php

Now, phpwcms should set the the according fields between the tags [de] [/de], [fr] [/fr] and [en] [/en].

The same for article details (article head).
For each contentpart, a language selector (eg. dropdown menu) would be enough. phpwcms would set the CPs between the according language tags.
For the shop module, it would be great to have the same for products and categories.

The frontend-render-script for language replacement would do the rest.

Santscho

[axelko]

Hi Santscho,

Do you mean just to have a easier interface for the multilanguage solution OG already made. Now you have to put all tags manually in the content parts and structure. [en]hello[/en][de]hallo[/de][nl]hoi[/nl]. With a lot of languages this becomes a bit 'messy' for the users who maintain the website.

Your suggestion would be nice to have but not really neccesary in my opinion because this functionality is already in phpwcms.

Greetz,

Axel

[santscho]

you are right. phpwcms should tag content with [en][/en]. Not the user. There is no new wheel to invent. Just more options in the input masks. I mean, for the content parts, it can also be something like field in which you can type "en" and phpwcms makes a validation (like in the "news" function of phpwcms).

I am working on two multi language projects. One of this is really big and we are planing now. I offert two solutions to the client. One is the multi-tree-solution (3 language trees) and a 1-tree-solution (with language replacement). I would like solution 2, because you manage all articles and pages on one place.

But honestly. That causes really confusion for the webmaster in future. No overview at all:


Additional fields for page info and header: completely enough. And wrapping contentparts with language tags by selecting the language in CP edit. a solution for content parts with selectable templates: creating for each template additional language templates and wrap them in language tags: [en]......[TITLE]div class="......>{TITLE}....[/TITLE].....[/en]

[axelko]

Santscho,

I'm also doing a great multilanguage project right now and your suggestion would be a welcome addon for the user. Exspecially for the title this would be nice because with 5 languages a title like [en]whatever text here[/en][de]egaal welcher tekste[/de][it]wdwdwderhr hr hr rh rr rrh r[/it][nl]zomaar een tekst[/][fr]une tet e h ht tret rth[/fr] is very difficult to maintain for an user.

Merry Xmas.

Axel

[juergen]

Hi guys,


why not doing this as every big gun does it ? trees for each language ? To easy ?

[santscho]

Hi Jürgen.
I think, the 3-trees-solution is okay for smaller website projects. But when it comes to a complex site structure with many articles, it is much more difficult to copy/paste the correct ContentParts from article "language A" to the articles "language B", "language C" and "language D". Because in the article central of phpwcms, it shows only which kind of CPs are in the article but not its content. It would be easier, to manage the different CPs for the different languages in the same article.

A workaround for a 1-tree-solution at the moment would be:
- Pages: working with the language tags
- Articles: working with the language tags (article head)
- CPs: working with language tag wrapped templates (eg. Teaser1_de.tmpl, Teaser1_fr.tmpl, Teaser1_en.tmpl)
or
-CP: working with only one template, which includes all 3 CP functions, wrapped by language tags.

[axelko]

Hi Jürgen,

And also you will have a lot of duplicate content and it is difficult to maintain all the different languages in a big site. I agree with santscho that for a small site the multi level structure is ok but for a large website the other solution. Only the user (editors) need to know what they are doing.

Greetz,

Axel

[update]

?????????????
EDIT:

EDIT2:
C'mon - there has to be a much more sophisticated solution for this one! It's simply not a matter of translating a site 1:1. Rather you will be forced to deal with country specifics for example. So you will end up with one site and 20 pages and another one will contain 30, each of them with a (slightly) different structure perhaps, due to different laws for example.... You will have to deal with it this way!

[axelko]

Hi (sante)Claus,

Yep that's what my project is right now. A 1:1 translation for all the languages. So all the pages are for every language in the structure. I know, it's very hard to maintain. If one language page is changed they'll have to change all the other language pages too and this gives problems because they aren't all native german, english, french, italian and dutch speakers. So after a while all the language pages aren't 1:1 anymore. But that's not a real problem, they just want to have a the same start point for all languages.

Greetz,

Axel

[Jensensen]

... very hard to maintain. If one language page is changed they'll have to change all the other language pages too and this gives problems because...

That's EXACTLY why WE

--> advice[d for many years] to use

...trees for each language...

--> are [a]wating [for YEARS]


--> need what was called
==> GURM


This means that, one day, finally, probably, temporarily, hopefully all site editors/personnel/staff

which can/must/have to work on their OWN articles (sub-trees)


==> CANNOT

fummel/access/change/edit


the English-BE's TREE
the French-BE's TREE,
the Netherlands-BE's TREE,
the Italian-BE's TREE,
the Danish-BE's TREE,
the Spanish-BE's TREE,
the Swedish-BE's TREE,
the Romanian-BE's TREE and so on...


UNTIL they are AUTHORIZED or ALLOWED to do so

===> due to a grained, dedicated GURM!

...the same start point for all languages...

==> home
==> lang root {TREE} [entry]


because {in my opinion} sometimes the 'tree' needs its own fertilizer { ==> templates, graphics...}
that any 1:1 utilization can't absorb.

but GURM [yes we] can!

[santscho]

Thank you all for your thoughts.

OG also recommends separate language trees. http://code.google.com/p/phpwcms/issues/detail?id=137.

But I still think, the function would be nice. Everybody could decide, how to build the website. And both ways would be comfortable in a way.

I wrote in my first posting:

In my point of view, this would be more important than the user management.

Stupid me. After reading the posting of Jensensen, I have to revise my statement. GURM should have first priority.

Have a nice sunday!

[ShyGuy]

I know the post is a bit old but still valid. I also see the need to simplify separating content with different languages but in my opinion the expanded multiple fields will increase the load and render time and helps not that much when the number of languages increases.

But what do you think about small check-boxes where the user can select the language(s) displayed in the backend - similar as the front-end does but keeping the active language tags visible and allowing multiple preferred selections for easier language-to-language translation.

I haven't noticed the tagged language switching before and are pretty happy - now I found it and got it running. Thank you !