Re: [pgsql-www] planet in more languages

Magnus, all,

* Magnus Hagander (magnus@hagander.net) wrote:
> On Sat, Jul 1, 2017 at 3:48 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
> > But what we want to do here is not that kind of language-in-country
> > specific code, but rather something that means "list me all blog posts
> > in either Spanish or French".  Which would be this "es_fr" weird thing
> >
> we've just invented.  Maybe we should specify that differently -- maybe
> > separate them with commas instead of underscore.  So
> > planet.pg.org/fr,es,en/ would mean entries in either French, Spanish,
> > English.
>
> Oh, i was not aware there was such a plan. I don't think that was mentioned
> anywhere (well, reading the submission once knowing that I guess it was,
> but without knowing that I didn't realize it).

Yeah, same.

> Anyway, for that to be the idea, then I think that yes we should specify it
> differently. If it looks *almost* like the syntax used for
> language/country, then it will be misunderstood by more people than just
> me. And you would also need to deal with collissions - for example "pt_br"
> uses that syntax but is AIUI actually supposed to be treated differently?

Agreed- using underscores here would be a really bad idea.

> Commas require escaping in URLs I believe (except in the querystring) so I
> don't think that's the best choice. Maybe just use a dot? So /fr.en.es/?
>
> And this being significantly more involved than just picking one language,
> we *definitely* need an interface for people to select what they want.

Given that we need an interface and that we need to have some rather
complex support for these options, have we considered maybe given an
option for a user to be logged in and their prefereneces (Whatever they
are, and they could be more complicated later...) taken into
consideration when generating the page for them?

In other words, forget the URL mangling to try and make this happen in a
complex way.  Maybe we still have the URL mangling for the 'simple'
cases ('/fr' or '/fr_FR' or whatever...) but not for the complex cases
where user X wants 'fr_FR' and 'fr_US' and 'en_US'...