[apostrophe] URLs and I18N

[Stéphane Erard]

Hi list,

I need to i18nize the urls. Is this possible ?

I have thought of this way :
create a xxUrl class which is related to a aPage, an aPage could have
many URLs (each for a different language, may be not; to be
discussed).

Then modify the main apostrophe route to match urls using this xxUrl
record class, and branch this code to existing apostrophe code.

Someone already did this ? Is this planned ?

Thanks !

[Tom Boutell]

Not planned so far. Are you aware of other systems that handle things
this way? I can see how it might work.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

[Stéphane]

No I'm not !

How do you see this ? :-)

Cheers,

Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Tom Boutell]

Well, it's not something we'd likely do any time soon, but something
like your suggested solution is possible. It's YAJ (Yet Another Join),
though.

[Stéphane Erard]

As it is something needed, and I think this is the most simple and
flexible way to go, doing YAJ doesnt make me feel bad :-)

Thank you !

Cheers,

[Daniel Kucharski]

Hi,

Instead of directly creating a xxUrl record class, maybe another idea
is to create a 'PageI18n' record class containing fields related to
translation, such as a localized slug (which could be used for URL),
localized page title, meta data (for SEO). Of course a join is
inevitable anyway.

I am currently myself also evaluating whether or not the Apostrophe is
suitable to replace my custom CMS. In my CMS I trigger localized
pages by adding the culture as first part of the url together with a
localized slug (http://zz.com/nl/dutch_page). I would love to see URL
I18N support in Apostrophe :-)

[Stéphane]

You are right ! Better this way !

Cheers,

Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Tom Boutell]

If this is what you really want, perhaps you should just build
separate trees for each culture, and redirect from the home page based
on the user's culture. No muss, no fuss, no changes to Apostrophe,
although you might override the show action to autoredirect people
from the root page to their culture's homepage unless they are admins
(and therefore need access to the hidden root page to add more
cultures etc).

[Daniel Lohse]

And how Tom's suggestion is done is explained here: http://www.symfony-project.org/jobeet/1_4/Doctrine/en/19

Daniel

[Stéphane]

With the latest recommandations, we will see the $dns/fr/ma-super-page

But the need is to not see this !
I have already asked about how to implement one-tree-per-culture, but this is not the need.

Thank you anyway !

Cheers,


Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Tom Boutell]

I thought that was what you wanted...?

How *do* you want it to work?

[Stéphane]

What I need is :

fr : $dns/ma-page
en : $dns/my-page

How to make it works ?

aPage18N:
  columns:
    slug: {type: string(255); notnull: true}
  relations:
    page:
      class: aPage
      type: one
      foreignType: many
  indexes:
    slug_idx: ...

An aPage18N record for each page times each culture. Or make use of actAs I18N (thus making YAN over the YAN ^^).

About apostrophe dev., it would be really nice to be able to change the aPage implementation by making use of the Doctrine_Template feature of Doctrine (the feature which let us change the implementation class at runtime). So we can easily extend-modify apostrophe ?

Cheers,


Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Daniel Kucharski]

Stéphane, you should always add the culture as part of your url when
you offer more than one language. You can have pages with the same
translation in multiple cultures. Eg. a 'contact' page should be in
Dutch $dns/nl/contact and in English $dns/en/contact . Or how else are
you going to make this kind of distinction?

> > On Thu, May 13, 2010 at 1:45 PM, Stéphane <stephane.er...@gmail.com>

> > wrote:
> > > With the latest recommandations, we will see the $dns/fr/ma-super-page
>
> > > But the need is to not see this !
> > > I have already asked about how to implement one-tree-per-culture, but
> > this
> > > is not the need.
>
> > > Thank you anyway !
>
> > > Cheers,
>
> > > Before Printing, Think about Your Environmental Responsibility!
> > > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
>
> > > On Thu, May 13, 2010 at 3:05 PM, Daniel Lohse <

> > annismcken...@googlemail.com>

> > > wrote:
>
> > >> And how Tom's suggestion is done is explained here:
> > >>http://www.symfony-project.org/jobeet/1_4/Doctrine/en/19
>
> > >> Daniel
>
> > >> On 13.05.2010, at 15:03, Tom Boutell wrote:
>
> > >> > If this is what you really want, perhaps you should just build
> > >> > separate trees for each culture, and redirect from the home page based
> > >> > on the user's culture. No muss, no fuss, no changes to Apostrophe,
> > >> > although you might override the show action to autoredirect people
> > >> > from the root page to their culture's homepage unless they are admins
> > >> > (and therefore need access to the hidden root page to add more
> > >> > cultures etc).
>

> > >> > On Thu, May 13, 2010 at 5:54 AM, Stéphane <stephane.er...@gmail.com>

> > >> > wrote:
> > >> >> You are right ! Better this way !
> > >> >> Cheers,
> > >> >> Before Printing, Think about Your Environmental Responsibility!
> > >> >> Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
>
> > >> >> On Thu, May 13, 2010 at 11:20 AM, Daniel Kucharski <

> > inspi...@gmail.com>

[Stéphane]

Well that's a good question, but there are answers I believe.

If user has selected a culture, it will be used (in the case two pages have the same slug for example).

If no choice has been made, request's first accepted language will be used.

Something like this ?

Cheers,

Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Quentin Dugauthier]

From a SEO point of view, you might get troubles referencing all your languages.

I had this discussion with a friend recently. Theoretically, a page is a ressource and should have a unique URL, no matter the language. This is why the accepted language headers are used for. But this is not always easy for bots to find all languages.
Here are some ressources that emerged during that discussion:
http://www.antezeta.com/blog/domains-seo
http://rafistern.wordpress.com/2008/06/02/tuning-localization-for-googlebot/
http://www.google.com/support/forum/p/Webmasters/thread?tid=22b3188f86c296f7&hl=en

KR,

Quentin.

[Stéphane]

Thank you very much for your insights, I will take a look at given resources and give you feedback about this.

Cheers,

Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Charles]

Hello,
I agree with Quentin (and Daniel). I plan to use apostrophe for one of
my client (a multilanguage website) , but it seems that aspostrophe
apostrophe doesn't manage URL internationalization. I checked the
project roadmap but i didn't see any tickets on that issue. Does
anyone know when (or if) i18n URL will be taken in account ?

Thank you for your answers.

Regards,
Charles

On May 14, 9:55 am, Quentin Dugauthier <dugauth...@gmail.com> wrote:
> From a SEO point of view, you might get troubles referencing all your
> languages.
>
> I had this discussion with a friend recently. Theoretically, a page is a
> ressource and should have a unique URL, no matter the language. This is why
> the accepted language headers are used for. But this is not always easy for
> bots to find all languages.

> Here are some ressources that emerged during that discussion:http://www.antezeta.com/blog/domains-seohttp://rafistern.wordpress.com/2008/06/02/tuning-localization-for-goo...http://www.google.com/support/forum/p/Webmasters/thread?tid=22b3188f8...
>
> KR,
>
> Quentin.

>
> On Fri, May 14, 2010 at 09:41, Stéphane <stephane.er...@gmail.com> wrote:
> > Well that's a good question, but there are answers I believe.
>
> > If user has selected a culture, it will be used (in the case two pages have
> > the same slug for example).
> > If no choice has been made, request's first accepted language will be used.
>
> > Something like this ?
>
> > Cheers,
>
> > Before Printing, Think about Your Environmental Responsibility!
> > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
>

[Tom Boutell]

Seems like you have separate subsites at that point and could just
host them at /en, /de, etc. and redirect to those from the home page
based on the user's culture (a small override to the a/show action
which would otherwise just call parent::execute). Once the URLs
themselves are translated the difference between what you want and
what I'm suggesting (that can be done with stock Apostrophe) is very
small.

[Charles]

Thank you very much for your quick response Tom.
If I understand your advice, the tree menu of the website should look
like this : http://dl.free.fr/vicN3oI7M (screenshot). The home page
will be invisible for website "external users".
This "hack" could work but in my humble opinion, it doesn't follow
the i18n symfony practices (http://www.symfony-project.org/jobeet/
1_4/Doctrine/en/19) and all advantages these practices give.

In fact i took a look at many CMS based and symfony, and i'm
considering to get involved in the Apostrophe Now project. But before
that i would like to "be reassured" on what direction the project will
take concerning internationalization. Most of my clients ask for
multilanguages websites and, still in my opinion, I18n sould be taken
in account very soon in a project.
I would be very interested to have your opinion in a PageI18n class
containing page translation attributes (page title, metadata page
keywords, metadata page description, slug...) ?

Thanks again for your answers.

Regards.
Charles

> >> Here are some ressources that emerged during that discussion:http://www.antezeta.com/blog/domains-seohttp://rafistern.wordpress.co......

[Tom Boutell]

Those Symfony i18n practices you pointed to don't provide translated
slugs either. And they suggest routes with the culture at the start of
the URL, just as I did.

I would make the home page for each language the /en page, /br page,
etc. rather than creating an unnecessary additional level by putting
the home page beneath that.

The default i18n behavior of Apostrophe is to use the same URL for all
cultures and switch the language of the content provided based on the
user's culture. To edit a page in another language you switch cultures
yourself and then start editing to create the content for that page in
that language. But you can internationalize the URLs instead if you
wish following my alternative suggestion.

[Charles]

Thank you Tom for your response. But i don't understand how to create
multi home pages from the apostrophe now interface ?
I need to have :
- $dns/home-page in english
- $dns/fr/page-accueil in french
- $dns/es/pagina-principal in spanish

Regards,
Charles

On Jun 10, 1:56 pm, Tom Boutell <t...@punkave.com> wrote:
> Those Symfony i18n practices you pointed to don't provide translated
> slugs either. And they suggest routes with the culture at the start of
> the URL, just as I did.
>
> I would make the home page for each language the /en page, /br page,
> etc. rather than creating an unnecessary additional level by putting
> the home page beneath that.
>
> The default i18n behavior of Apostrophe is to use the same URL for all
> cultures and switch the language of the content provided based on the
> user's culture. To edit a page in another language you switch cultures
> yourself and then start editing to create the content for that page in
> that language. But you can internationalize the URLs instead if you
> wish following my alternative suggestion.
>

> On Thu, Jun 10, 2010 at 6:25 AM, Charles <jc.du...@gmail.com> wrote:
> > Thank you very much for your quick response Tom.
> > If I understand your advice, the tree menu of the website should look

> > like this :http://dl.free.fr/vicN3oI7M(screenshot). The home page

> ...
>
> read more »

[Tom Boutell]

1. Make subpages for /fr, /es, /en, etc. Don't call them
/en/home-page, that would be redundant, just call them /en, /es, etc.

2. Write a custom action for the "root" home page which redirects you
to the appropriate sub-homepage (/fr or /es or /en). Put the route for
this action in your routing.yml *before* the a_page route so it "wins"
for the / URL. You could get fancy and check whether the user is the
superadmin and if they are give them a form to make a new subpage for
a new language if they want.

Writing actions, issuing redirects, etc. is just Symfony programming
and I refer you to the Jobeet tutorial if you have not already
completed it.

--

[Charles]

Thanks Tom.

I've found a solution for i18n pages.I'll a post my "hack" in a few
days.

Here is what i did to add meta-tags to pages :
Screenshot : http://dl.free.fr/ryoAywidB/apostrophe.jpg

- I added these lines in the config/doctrine/schema.yml
aPage:
columns:
keywords:
type: string(255)
description:
type: string(255)

- In apps\frontend\modules\a\actions\actions.class.php i added :
public function executeShow(sfWebRequest $request)
{ ......
$this->getResponse()->addMeta('keywords', $page->keywords);
$this->getResponse()->addMeta('description', $page->description);
......
return 'Template';
}
- In lib\form\doctrine\apostrophePlugin\aPageSettingsForm.class.php i
added :
class aPageSettingsForm extends aPageForm
{
...
public function configure()
{
parent::configure();
....
$this->setWidget('keywords', new sfWidgetFormTextarea());
$this->setWidget('description', new
sfWidgetFormTextarea());
....


It works but it's not clean because my code is too intrusive. When
i'll upgrade my project to the next apostrophe version, i'll have make
changes again to aPageSettingsForm.
My method don't follow the best practices. So my question is : is
there a way to add these meta-tags in a clean way by making a plugin ?

Thanks in advance.
Charles

On Jun 14, 5:11 pm, Tom Boutell <t...@punkave.com> wrote:
> 1. Make subpages for /fr, /es, /en, etc. Don't call them
> /en/home-page, that would be redundant, just call them /en, /es, etc.
>
> 2. Write a custom action for the "root" home page which redirects you
> to the appropriate sub-homepage (/fr or /es or /en). Put the route for
> this action in your routing.yml *before* the a_page route so it "wins"
> for the / URL. You could get fancy and check whether the user is the
> superadmin and if they are give them a form to make a new subpage for
> a new language if they want.
>
> Writing actions, issuing redirects, etc. is just Symfony programming
> and I refer you to the Jobeet tutorial if you have not already
> completed it.
>

> On Mon, Jun 14, 2010 at 4:56 AM, Charles <jc.du...@gmail.com> wrote:
> > Thank you Tom for your response. But i don't understand how to create
> > multi home pages from the apostrophe now interface ?
> > I need to have :
> > - $dns/home-page in english
> > - $dns/fr/page-accueil in french
> > - $dns/es/pagina-principal in spanish
>
> > Regards,
> > Charles
>
> > On Jun 10, 1:56 pm, Tom Boutell <t...@punkave.com> wrote:

> >> Those Symfonyi18npractices you pointed to don't provide translated

> >> slugs either. And they suggest routes with the culture at the start of
> >> the URL, just as I did.
>
> >> I would make the home page for each language the /en page, /br page,
> >> etc. rather than creating an unnecessary additional level by putting
> >> the home page beneath that.
>

> >> The defaulti18nbehavior of Apostrophe is to use the same URL for all

> >> cultures and switch the language of the content provided based on the
> >> user's culture. To edit a page in another language you switch cultures
> >> yourself and then start editing to create the content for that page in
> >> that language. But you can internationalize the URLs instead if you
> >> wish following my alternative suggestion.
>
> >> On Thu, Jun 10, 2010 at 6:25 AM, Charles <jc.du...@gmail.com> wrote:
> >> > Thank you very much for your quick response Tom.
> >> > If I understand your advice, the tree menu of the website should look
> >> > like this :http://dl.free.fr/vicN3oI7M(screenshot). The home page
> >> > will be invisible for website "external users".
> >> > This "hack" could work but in my humble opinion, it doesn't  follow

> >> > the  i18nsymfony  practices (http://www.symfony-project.org/jobeet/

> >> > 1_4/Doctrine/en/19) and all advantages these practices give.
>
> >> > In fact i took a look at many CMS based and symfony, and i'm
> >> > considering  to get involved in the Apostrophe Now project. But before
> >> > that i would like to "be reassured" on what direction the project will
> >> > take concerning internationalization. Most of my clients ask for

> >> > multilanguages websites and, still in my opinion,I18nsould be taken

> >> > in account very soon in a project.
> >> > I would be very interested to have your opinion in a PageI18n class
> >> > containing page translation attributes (page title, metadata page
> >> > keywords, metadata page description, slug...) ?
>
> >> > Thanks again for your answers.
>
> >> > Regards.
> >> > Charles
>
> >> > On Jun 9, 5:51 pm, Tom Boutell <t...@punkave.com> wrote:
> >> >> Seems like you have separate subsites at that point and could just
> >> >> host them at /en, /de, etc. and redirect to those from the home page
> >> >> based on the user's culture (a small override to the a/show action
> >> >> which would otherwise just call parent::execute). Once the URLs
> >> >> themselves are translated the difference between what you want and
> >> >> what I'm suggesting (that can be done with stock Apostrophe) is very
> >> >> small.
>
> >> >> On Wed, Jun 9, 2010 at 11:28 AM, Charles <jc.du...@gmail.com> wrote:
> >> >> > Hello,
> >> >> > I agree with Quentin (and Daniel). I plan to use apostrophe for one of
> >> >> > my client (a multilanguage website) , but it seems that aspostrophe
> >> >> > apostrophe doesn't manage URL internationalization. I checked the
> >> >> > project roadmap but i didn't see any tickets on that issue. Does

> >> >> > anyone  know when (or if)i18nURL will be taken in account ?

> >> >> >> >> >I18N(thus making YAN over the YAN ^^).

> ...
>
> read more »

[Tom Boutell]

Hi Charles,

You can extend the executeShow method at the project level without
copying and pasting the whole thing. Just call parent::executeShow()
first, save the result in a variable, do your extra stuff, and then
return the result variable.

Similarly, if you update your svn checkout of the Apostrophe 1.4
branch, you'll find that I recently fixed aPageSettingsForm to extend
BaseaPageSettingsForm, so you can extend it at the project level
without copying and pasting all of the code.

Unfortunately you cannot extend one plugin in another plugin cleanly
in Symfony 1.4 - that's a limitation of Symfony, not Apostrophe. I
believe this limitation is expected to go away in Symfony 2.0 because
of the more flexible way bundles work. You could bundle your changes
as static methods in a class in a plugin and provide instructions on
where to paste in a few calls to make it work.

However we do plan to add meta tags and descriptions to the core of
Apostrophe, likely in 1.5. We need tags anyway because they greatly
simplify many otherwise complicated questions about how to customize a
particular instance of an engine page, etc.

So it would probably be easier to just wait for us to do that.

--

[Stéphane]

Hi,

What about instanciating events at some points in apostrophe code so apostrophe users (developers) can plug in some codes ?

Is there a pro/con ? I speak for sf1.4, of course sf2 osgi-style will be cleaner for this.

Cheers,

Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!

[Tom Boutell]

It could happen, but if you go hog wild with events you wind up with
Drupal. Hard to figure out what is going on, hard to maintain, hard to
debug.