[Theforum] Re: langs

Tue Nov 13 03:23:15 CST 2001

michele,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Michele Foster
>
> | there are provisions for marking an article as being
> | in a particular language (ie, there's a languageid
> | column in the content table).  that bit of information
> | has just never been used or expanded.
>
> If I understand correctly, the above would be minimal
> amount of effort required, to proceed??
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

well, sort of.  the risk we run of going with a solution like this is
fragmenting our content into multiple languages and having to separate them
all later when/if we implement the more appropriate strategy i'm suggesting.

for this temporary solution, we have to do *very* little to display the
content in those languages that use charset iso-8859-1
(http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset4
.asp).

however, for *any* language that would need to use a different charset, we'd
need to make some subtle changes to the way the cms works.  we'd have to add
a table to catalogue languages and their various attributes like charset,
the correct lang attribute value for the <html>, <meta> description, and
<meta> keywords tags, etc.

when displaying an article (the rest of the site would default automatically
to english, something we could address later with my suggested development)
we'd need to get the appropriate attribute values for the content based on
the languageid for the content and make the necessary changes to the items
mentioned above.

non-english language content poses some problems though.  my feeling is that
the synopsis (and probably title as well) should be in english.  throwing
(which is what we'd be doing to all our users who are used to english-only
content) a non-english article into the mix would be *highly* confusing if
it's not qualified (yeah, i know users who's native tongue is the same as
the article would recognize it immediately, but do we really know what
percentage of our audience accounts for?).  so, i think the possible
solution in the short-term would be to query out the language the article is
in and display that as an additional attribute in the article listings.  for
example:

10/11/2001  User-Defined Window Targeting w/ JavaScript
      Code  Author: .jeff - [Language: en-us]
            A member of thelist recently inquired about
            a JavaScript that would give the visitor of
            his webpage the choice of whether links
            should open in the same window, a new window
            for all, or new windows for each. I figured
            this was a fun opportunity to write the
            JavaScript to allow the user to choose the
            target of certain links on the page. [Full
            article...] - [Comments: 3] - [Rating: 4.63
            - Ratings: 8]

notice the "Language: en-us" bit right after the author?  now, obviously as
we move to an implementation where the entire cms's display is language
specific, we'll want to use identifiers (the "Language:" bit) from the
user's selected language to view the site.

for example, the above (babelfished into spanish-esque) might look like
this:

10/11/2001  Window de User-Defined que apunta con JavaScript
    Código  Autor: .jeff - [Lenguaje: en-us, es]
            Un miembro del thelist investigó recientemente
            sobre un JavaScript de el cual daría al
            visitante de su webpage la opción si las
            conexiones deben abrirse en el mismo Window, un
            Window nuevo para todos, o los Windows nuevos
            para cada uno. Calculé esto era una oportunidad
            de la diversión de escribir el JavaScript para
            permitir que el utilizador elija la blanco de
            ciertas conexiones en la paginación [Artículo
            completo...] - [Los comentarios: 3] - [Grado:
            4,63 - Grados: 8]

back to the temporary solution, including the "[Language:]" identifier
*might* alleviate the need to have the title and synopsis in english.

now, with the idea i have in mind for the future, starting out like this
could reap some really cool benefits.  for example, all users could specify
what language they want to view the site in.  all the various identifiers
throughout the site are retrieved in that selected language.  additionally,
the user could specify in their preferences whether or not to suppress
articles that aren't available in their preferred language.  when the user
encounters an article available in multiple languages (as noted in the
"Language:" identifier) he can either click the title of the article or the
"Full article..." link and be taken to the article selected in his preferred
language by default.  or, each of the language identifiers could be links to
the article forcing the chosen language to retrieve the article in to
override the user's defaults.

this would change the above display slightly to include as many language
identifiers in the "Language:" identifier as the article has available
translations.  here's an example of the article above in english (us),
romanian, and spanish (language codes found here:
http://xml.coverpages.org/iso639a.html)

10/11/2001  User-Defined Window Targeting w/ JavaScript
      Code  Author: .jeff - [Language: en-us, ro, es]
            A member of thelist recently inquired about
            a JavaScript that would give the visitor of
            his webpage the choice of whether links
            should open in the same window, a new window
            for all, or new windows for each. I figured
            this was a fun opportunity to write the
            JavaScript to allow the user to choose the
            target of certain links on the page. [Full
            article...] - [Comments: 3] - [Rating: 4.63
            - Ratings: 8]

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> | imho, our data structure isn't built to appropriately
> | handle multi-language (ie, an article that's been
> | translated into several languages) articles.
>
> Yup, can see that .. based on previous discussions in
> the past.  Remember when we were talking about the
> linking related articles feature, could this be done in
> a similar manner?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

sure, it could be done a number of ways.  however, doing it in "related
articles" fashion will cause all sorts of nightmares.  it will fragment
connected content (ie, same article but different languages) across the site
rather than pulling together the commonality of the article.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> | in order for different language versions of the same
> | article to share the contentid, we'd need a child
> | table to hold the language specific content.
>
> Ok, I understand this sort of.  Why must the different
> language versions hold the same article contentID ?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

connecting a single piece of content who's only different from piece to
piece is the actual language the content resides in is crucial to being able
to connect it all together.  think of things like comments.  suppose i'm a
multi-language user and can read/write english and spanish.  it would be
nice if i could view an article in my preferred language along with comments
in any number of languages they're submitted in.

for example, let's suppose we have an article that's available in both
english and spanish.  my preferences are set to default articles to english,
but display all comments that are in english or spanish.  since both
translations of the article reside under a single contentid it's *very* easy
to extract the comments and display them to the user.

remember, there's more things tied to contentid than just the article
content.  additionally, the author of a particular piece of content is still
the author even if the content is translated.  so, that author should get
credit for both versions and another user should get credit for the
translation (but not the same sort of credit an author would get).  all
ratings for an article (regardless of what language the user was viewing it
in) should apply together.  are you seeing the necessity for articles in
varying language versions to be tied to a single contentid?

let me give another example of why the contentid is important.  take this
url for example:

http://evolt.org/article/view/17/16286/

now, suppose i have english set as my default language and the article is
available in english and french.  also let's suppose i'm already logged in.
the system checks the language i prefer to read articles in when it grabs
the content, making sure to grab the english version.  it also grabs a list
of all the languages the article is available in beyond the language version
being currently viewed.  in this article's case, it displays that the
article is also available in french with a link to that version.  let's say
i have a friend who only speaks french and is not a registered user of
evolt.org.  i can send him this french version link and he'll be able to
view the content in french.  that link might look like:

http://fr.evolt.org/article/view/17/16286/

the english version would be at (despite the user's preferred language
settings):

http://en.evolt.org/article/view/17/16286/

while the two links below would default to english if the user is not logged
in or would default to the logged in user's chosen language.

http://evolt.org/article/view/17/16286/
http://www.evolt.org/article/view/17/16286/

the beauty of this approach making sense to anyone yet?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> I'm curious to know what the estimated time of
> completion would be if we wanted to implement the
> entire shebang.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

unfortunately there is nowhere near enough information yet to determine
that.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> I'm leaning very muct towards Matt's idea, that only if
> the article is also in English;
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

unfortunately that will only serve to make our job harder later should we
decide to go in the direction i'm suggesting as doing two versions of the
article will cause identical content (with the only difference being the
language) to be separated by different contentids.  if we implement the
multi-language system i'm talking about, a multi-language article such as
this using our existing system would become a nasty exception we'd either
have to live with (ie either the article is available in multiple languages
but not linked and therefore does not behave like any of the other ones or
one of the language versions becomes a broken link in order to merge the two
language versions into a single piece of content) or code exceptions for
(yuck).

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> IOW, what's it going to cost us to implement.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

very good question, the answer of which cannot yet be determined.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Do we really want to spend the time doing this?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i don't know.  i think it would bring an incredible new level of emphasis on
the globalness of our community.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Do we have other projects more pressing that we should
> continue to work on.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

we should definitely continue working on projects that are further along in
development while continuing the discussion of the problem we're trying to
solve and what the best solution might be.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> We'd need to define a list of article reviewers on-hand,
> for other languages.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

not necessarily.  the necessity for article reviewers would only come when
we had an article in another language that needed to be reviewed.  we've
gone how long so far with only one opportunity at a non-english article?  i
don't think approving one will cause a sudden surge.  *grin*

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> This is good Jeff .. so, what kind of time/effort would
> we be looking at to implement something like this?  I
> realize it will be generalized, as not all the final
> details have been worked out.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

unfortunately still far too generalized to make any guestimations on the
resource expenditure for a project like this.

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/