Обсуждение: [pgsql-www] planet in more languages
Hello,
This patch allow urls such as planet.postgresql.org/en/ or planet.postgresql.org/es-it-fr/ to display entries in the selected languages.
The planet.postgresql.org url automatically redirects planet.postgresql.org/en/ to maintain current behavior.
Вложения
Hi!
Thanks, this looks like a pretty good start. A few comments:
I don't particularly like a redirect to /en/ -- let's just keep english at the /, and use /fr/ or whatnot for other languages.
Do we really need to prepopulate *all* languages? I suggest we add languages as necessary, and instead have a text somewhere asking people to email us to add more languages if requested. That's also going to give a much easier to use interface.
The patch fails to take care of RSS feeds.
The planet page in non-english still comes with english menu entries and headlines. I don't think we need (or even want) the registration interface to be translated, but the headlines about teams and feeds and such probably should be. And the plain texts.
//Magnus
On Thu, Jun 15, 2017 at 12:43 AM, Daymel Bonne <daymel.bonne@2ndquadrant.ec> wrote:
Hello,Seeing that the old idea of having a planet in more languages had a good feedback from the community, I made a patch that allows separate language feeds.This patch allow urls such as planet.postgresql.org/en/ or planet.postgresql.org/es-it-fr/ to display entries in the selected languages. The planet.postgresql.org url automatically redirects planet.postgresql.org/en/ to maintain current behavior.Regards--
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
On 29 June 2017 at 09:04, Magnus Hagander <magnus@hagander.net> wrote: > > Do we really need to prepopulate *all* languages? I suggest we add languages > as necessary, and instead have a text somewhere asking people to email us to > add more languages if requested. That's also going to give a much easier to > use interface. > that also allow us to put some restrictions, for example to add a language we can ask that they translate the planet policy on the wiki > The patch fails to take care of RSS feeds. > > The planet page in non-english still comes with english menu entries and > headlines. I don't think we need (or even want) the registration interface > to be translated, but the headlines about teams and feeds and such probably > should be. And the plain texts. > what about the case in which someone uses es_fr? it should come in spanish or french? translation of the interface should, IMHO, happen at a different level (and that is a different patch) -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jun 30, 2017 at 6:09 AM, Jaime Casanova <jaime.casanova@2ndquadrant.com> wrote:
On 29 June 2017 at 09:04, Magnus Hagander <magnus@hagander.net> wrote:
>
> Do we really need to prepopulate *all* languages? I suggest we add languages
> as necessary, and instead have a text somewhere asking people to email us to
> add more languages if requested. That's also going to give a much easier to
> use interface.
>
that also allow us to put some restrictions, for example to add a
language we can ask that they translate the planet policy on the wiki
That's a very good point.
> The patch fails to take care of RSS feeds.
>
> The planet page in non-english still comes with english menu entries and
> headlines. I don't think we need (or even want) the registration interface
> to be translated, but the headlines about teams and feeds and such probably
> should be. And the plain texts.
>
what about the case in which someone uses es_fr? it should come in
spanish or french?
translation of the interface should, IMHO, happen at a different level
(and that is a different patch)
es_fr means the french version of spanish, does it not? I'm not sure even what that is :) But if it has it's own language code, it should be treated like everything else?
Magnus Hagander wrote: > On Fri, Jun 30, 2017 at 6:09 AM, Jaime Casanova < > jaime.casanova@2ndquadrant.com> wrote: > > > The planet page in non-english still comes with english menu > > > entries and headlines. I don't think we need (or even want) the > > > registration interface to be translated, but the headlines about > > > teams and feeds and such probably should be. And the plain texts. > > > > > > > what about the case in which someone uses es_fr? it should come in > > spanish or french? translation of the interface should, IMHO, > > happen at a different level (and that is a different patch) > > es_fr means the french version of spanish, does it not? I'm not sure even > what that is :) But if it has it's own language code, it should be treated > like everything else? Not really ... codes like es_AR are supposed to mean "Spanish, in Argentina" (so you can have fr_CA and en_CA for French and English in Canada, and also es_ES and es_CL for Spanish in Spain or Chile). This configures not only language but also things like currency format, thousands separator, etc, which are country-specific rather than language-specific. 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. As for what language should the interface be in, I suggest to use the first language listed in the language specification. If you use /fr,es/ then show the interface in French, but if you use /es,fr/ then list it in Spanish -- though in both cases you would see exactly the same blog entries. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 1 Jul 2017, at 14:48, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Magnus Hagander wrote: >> On Fri, Jun 30, 2017 at 6:09 AM, Jaime Casanova < >> jaime.casanova@2ndquadrant.com> wrote: > >>>> The planet page in non-english still comes with english menu >>>> entries and headlines. I don't think we need (or even want) the >>>> registration interface to be translated, but the headlines about >>>> teams and feeds and such probably should be. And the plain texts. >>>> >>> >>> what about the case in which someone uses es_fr? it should come in >>> spanish or french? translation of the interface should, IMHO, >>> happen at a different level (and that is a different patch) >> >> es_fr means the french version of spanish, does it not? I'm not sure even >> what that is :) But if it has it's own language code, it should be treated >> like everything else? > > Not really ... codes like es_AR are supposed to mean "Spanish, in > Argentina" (so you can have fr_CA and en_CA for French and English in > Canada, and also es_ES and es_CL for Spanish in Spain or Chile). This > configures not only language but also things like currency format, > thousands separator, etc, which are country-specific rather than > language-specific. > > 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. > > As for what language should the interface be in, I suggest to use the > first language listed in the language specification. If you use > /fr,es/ then show the interface in French, but if you use /es,fr/ then > list it in Spanish -- though in both cases you would see exactly the > same blog entries. Maybe use get variables something like this? planet.pg.org/fr/?langs=fr,es,en That would be an interface lang of "fr", and showing posts in the languages fr, es, en. With a default to whatever the interface language is if no ?langs= variable is provided. + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Sat, Jul 1, 2017 at 3:48 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
-- Magnus Hagander wrote:
> On Fri, Jun 30, 2017 at 6:09 AM, Jaime Casanova <
> jaime.casanova@2ndquadrant.com> wrote:
> > > The planet page in non-english still comes with english menu
> > > entries and headlines. I don't think we need (or even want) the
> > > registration interface to be translated, but the headlines about
> > > teams and feeds and such probably should be. And the plain texts.
> > >
> >
> > what about the case in which someone uses es_fr? it should come in
> > spanish or french? translation of the interface should, IMHO,
> > happen at a different level (and that is a different patch)
>
> es_fr means the french version of spanish, does it not? I'm not sure even
> what that is :) But if it has it's own language code, it should be treated
> like everything else?
Not really ... codes like es_AR are supposed to mean "Spanish, in
Argentina" (so you can have fr_CA and en_CA for French and English in
Canada, and also es_ES and es_CL for Spanish in Spain or Chile). This
configures not only language but also things like currency format,
thousands separator, etc, which are country-specific rather than
language-specific.
Roght.
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).
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?
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.
As for what language should the interface be in, I suggest to use the
first language listed in the language specification. If you use
/fr,es/ then show the interface in French, but if you use /es,fr/ then
list it in Spanish -- though in both cases you would see exactly the
same blog entries.
If we want them to be different, let's specify them fully. So in your example, it'd be /fr/fr,es/ (maybe not comma, but that's separate). That'd make it very clear to both the user and the system what was intended.
But again, we very definitely need an interface for the user to set this up, we can't expect people to figure something like that out automatically.
On Sat, Jul 1, 2017 at 5:30 PM, Justin Clift <justin@postgresql.org> wrote:
There's no real difference in using a querystring or using the path part of the URL (arguably it looks nicer using just he URL, but that's mostly irrelevant), but yes clearly separating the language of the interface vs the language of the posts I think we definitely want.Maybe use get variables something like this?On 1 Jul 2017, at 14:48, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Magnus Hagander wrote:
>> On Fri, Jun 30, 2017 at 6:09 AM, Jaime Casanova <
>> jaime.casanova@2ndquadrant.com> wrote:
>
>>>> The planet page in non-english still comes with english menu
>>>> entries and headlines. I don't think we need (or even want) the
>>>> registration interface to be translated, but the headlines about
>>>> teams and feeds and such probably should be. And the plain texts.
>>>>
>>>
>>> what about the case in which someone uses es_fr? it should come in
>>> spanish or french? translation of the interface should, IMHO,
>>> happen at a different level (and that is a different patch)
>>
>> es_fr means the french version of spanish, does it not? I'm not sure even
>> what that is :) But if it has it's own language code, it should be treated
>> like everything else?
>
> Not really ... codes like es_AR are supposed to mean "Spanish, in
> Argentina" (so you can have fr_CA and en_CA for French and English in
> Canada, and also es_ES and es_CL for Spanish in Spain or Chile). This
> configures not only language but also things like currency format,
> thousands separator, etc, which are country-specific rather than
> language-specific.
>
> 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.
>
> As for what language should the interface be in, I suggest to use the
> first language listed in the language specification. If you use
> /fr,es/ then show the interface in French, but if you use /es,fr/ then
> list it in Spanish -- though in both cases you would see exactly the
> same blog entries.
planet.pg.org/fr/?langs=fr,es,en
That would be an interface lang of "fr", and showing posts in the languages
fr, es, en. With a default to whatever the interface language is if no
?langs= variable is provided.
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'...
> > As for what language should the interface be in, I suggest to use the
> > first language listed in the language specification. If you use
> > /fr,es/ then show the interface in French, but if you use /es,fr/ then
> > list it in Spanish -- though in both cases you would see exactly the
> > same blog entries.
>
> If we want them to be different, let's specify them fully. So in your
> example, it'd be /fr/fr,es/ (maybe not comma, but that's separate). That'd
> make it very clear to both the user and the system what was intended.
This could be done on a per-user basis if we give users such an option..
> But again, we very definitely need an interface for the user to set this
> up, we can't expect people to figure something like that out automatically.
Agreed, and if we're going there, seems like maybe we should save the
result in a database where the data is associated with the user...
Thanks!
Stephen
On Sun, Jul 2, 2017 at 6:20 PM, Stephen Frost <sfrost@snowman.net> wrote:
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?
A full login seems unnecessarily complicated, TBH. With requirements on signups and email address and whatnot.
But it seems it would be a good idea to store the preferences in a browser cookie for example.
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'...
That's one option yeah. We definitely need *some* level URL addressability so people can send links around.
--
* Magnus Hagander (magnus@hagander.net) wrote:
> On Sun, Jul 2, 2017 at 6:20 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > 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?
>
> A full login seems unnecessarily complicated, TBH. With requirements on
> signups and email address and whatnot.
Except that most people are likely to have an account already..? This
would only be for individuals who wish for a more personalized planet
feed.
> But it seems it would be a good idea to store the preferences in a browser
> cookie for example.
That would also be better than trying to encode it all into a URL.
> > 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'...
>
> That's one option yeah. We definitely need *some* level URL addressability
> so people can send links around.
Right, I agree with that, I just don't think we need to clutter up the
URLs that users use to get the overall feed with tons of complication.
Each feed should go into a simple category and that's what all the links
use and then there's a way for users to configure the combinations of
feeds they wish to see.
I don't know enough about other places and languages, but are we sure
that "language" is the level we'll always need, and that we don't need
(and don't want) to go to the two-level "language/country" that leads to
things like 'en_US'? I ask specifically because if we think we'll want
language/country, then I expect we'll want wildcards.
Thanks!
Stephen