Allow tagging of comments with language (at time of
posting).
Allow registered users to set their preference for
languages that they wish to read.
Allow registered users to set their default posting
language.
I just don't see this as being that important a feature... though it wouldn't be that hard to do, we just don't have a need for it... if a reader wants to do this and submit a patch, we'll certainly consider it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would encourage any potential implementers of this feature
to consider the fact that HTTP already has language
negotiation built into the protocol. Slash could key off of
this information along with user preferences to decide
whether or not to display an article in another language, or
in deciding which language of a multi-lingual article to
display. Strictly speaking there's no need to have these
settings in slash (except maybe a preference to enable or
disable the functionality entirely), since it already exists
in the web browser.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been thinking about this some more, and I might
even take a stab at implementation. Here were my
thoughts, with each one somewhat independent:
1. Multiple versions of an article depending upon
language
To preserve the concept that one article ID maps to one
article, perhaps change the database such that articles
are not keyed totally on article ID, but on article ID + a
language tag.
This language tag can be determined by selecting
the "best language" based on the user's prefs
(expressed through HTTP), perhaps multiplied by a
server-side metric (e.g. giving more weight to versions of
articles in their native language over translations).
2. Tag articles and comments with a language, like the
submitter said. Create a drop-down on article/comment
entry that allows the user to specify a different
language, defaulting to a user pref.
3. Allow for filtering of comments and articles based on a
user's language preference (as expressed through
HTTP). Enable this feature through a user's prefs, but
leave the actual language selection in HTTP.
I believe there's an HTTP::Negotiation module for doing
various types of HTTP content negotiation. That could
be useful here for situations where doing a simple
MultiViews-based selection is unworkable (e.g. building
a comment list that only contains comments in a certain
language).
4. Potentially offer machine language translations of
comments outside of a user's language set.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=3889
I just don't see this as being that important a feature... though it wouldn't be that hard to do, we just don't have a need for it... if a reader wants to do this and submit a patch, we'll certainly consider it.
Logged In: YES
user_id=3660
Moved to 2.3/2.4, as even if we do add this, it will not be
to 2.0 or 2.2 codebases, which are strictly in maintenance.
Logged In: YES
user_id=354672
I would encourage any potential implementers of this feature
to consider the fact that HTTP already has language
negotiation built into the protocol. Slash could key off of
this information along with user preferences to decide
whether or not to display an article in another language, or
in deciding which language of a multi-lingual article to
display. Strictly speaking there's no need to have these
settings in slash (except maybe a preference to enable or
disable the functionality entirely), since it already exists
in the web browser.
Logged In: YES
user_id=354672
I've been thinking about this some more, and I might
even take a stab at implementation. Here were my
thoughts, with each one somewhat independent:
1. Multiple versions of an article depending upon
language
To preserve the concept that one article ID maps to one
article, perhaps change the database such that articles
are not keyed totally on article ID, but on article ID + a
language tag.
This language tag can be determined by selecting
the "best language" based on the user's prefs
(expressed through HTTP), perhaps multiplied by a
server-side metric (e.g. giving more weight to versions of
articles in their native language over translations).
2. Tag articles and comments with a language, like the
submitter said. Create a drop-down on article/comment
entry that allows the user to specify a different
language, defaulting to a user pref.
3. Allow for filtering of comments and articles based on a
user's language preference (as expressed through
HTTP). Enable this feature through a user's prefs, but
leave the actual language selection in HTTP.
I believe there's an HTTP::Negotiation module for doing
various types of HTTP content negotiation. That could
be useful here for situations where doing a simple
MultiViews-based selection is unworkable (e.g. building
a comment list that only contains comments in a certain
language).
4. Potentially offer machine language translations of
comments outside of a user's language set.