Subject: [LON-CAPA-dev] <languageblock> / <translated>

From: Stefan Bisitz <[email-masked]>
Date: Fri, 06 Jul 2007 12:40:08 +0200

Guy Albertelli wrote:

> http://zaphod.lite.msu.edu/bugzilla/show_bug.cgi?id=4816
> [...]
> I'm think a better possibility might be something like
>
> <translated>
>    <lang code="de">
>        This is German
>    </lang>
>    <lang which="es">
>        This is Spainish
>    </lang>
>    <lang which="default">
>        This is what is shown for all others.
>    </lang>
> </translated>
>
> That way the parser can discover what translations there are and pick
> the first best one that applies. (First look if there is one that
> matches the course setting, if not pick the one that fits the user's
> pref, the the browser, then the domain and finally if exhausted show
> the default.)

[...]

> > There are still many unsolved issues concerning this topic.

> What issues do you see as being unresolved?

<translated>
  - Do the attributes "code" and "which" have the same meaning?
  - The structure is fine - just what we need
  - Is it easy to include this in LON-CAPA? Any other consequences?

<languageblock>
  - Bug?: <languageblock> sometimes provides different language
depending on where it is used: a) inside scriptblock with &xmlparse b)
inside textblock (example is available)
  - Who has used the <languageblock> so far?
  - How has <languageblock> been used until now? Don't we all use
<languageblock> as it had the functionality of <translated>?
  - Is there any practical use of <languageblock>? Why should one want
to have more than one valid language inside a problem? Any examples? We
are still searching...
  - LON-CAPA seems to create a list of valid language during runtime. Is
this an unordered list or is it hierarchically ordered by the priorities
(user pref, browser lang., etc.)?
  - Still unsure, if <languageblock> works correct (see bug 4816), e.g.
it seems that the second prefered browser language has higher priority
than the first.

<translated> vs. <languageblock>
  - What, if a CC wants to include a problem in a special language in
his course, but doesn't know if the author has used <translated> or
<languageblock>?
  - Eventually, authors would prefer <translated> as it is standard to
have only one valid language inside a problem.
  - Do we need to have the possibility to combine <languageblock> and
<translated>? (One of the tags nested into the other one)
  - Authors need to know which one of these two tags they should use for
what occasion. Documentation is necessary.

Metadata, Search
  - How to mark a problem as being available in more than one language,
e.g. German and English?  Currently, only one language could be choosen
in the metadata.
  - How can I find out, which kind (<languageblock> or <translated>) is
used? Search and metadata both don't provide this information.

New function to access valid language during runtime
(Already discussed before)
In the script block it is sometimes necessary to fill variables with
values depending on the valid language. Using &xmlparse with
<languageblock>/<translated> is too complicated and impractical. The
idea was to implement a new function which provides the current
language. Question is, if this function should offer a) (prefered) only
one language - the one with top priority (-> <translated>) or b) a list
of all valid languages (-> <languageblock>).

Summary:
- Do we really need <languageblock>?
- <translated> offers the functionality which is needed and which we
expected from <languageblock>.
- Some enhancements are necessary to reach full multilingual
functionality for LON-CAPA problems.

Stefan Bisitz

---

From: Guy Albertelli II <[email-masked]>
Date: Fri, 6 Jul 2007 14:25:12 -0400 (EDT)

Hi Stefan,

>   - Do the attributes "code" and "which" have the same meaning?

Sorry. I had meant to use "which" in all sections.

>   - Is it easy to include this in LON-CAPA? Any other consequences?

This should be easy. I don't forsee any reason for any difficulties.

> inside textblock (example is available)

I'd be curious to see this example. Just to make sure it isn't
anything we haven't already identified as an issue.

>   - Who has used the <languageblock> so far?

As far as I see your domain is the only user. But the portugese, or
Korean users may have made use of this in the past.

>   - How has <languageblock> been used until now? 

However you have attempted to use it is how it has been used as far as
I can tell.

> Don't we all use

<translated> only exists as an idea in my head (and in that bug
report) I'm proposing as a replacement for the broken by design
<languageblock> since as it exists right now <languageblock> seems
like an unworkable solution to the desire/need to have translations in
a homework problem becuse of issues you seen with <languageblock> so
far.

So, yes, "we all use <languageblock>" right now since that is all that
exists right now.

<translated> is a suggestion I'm making to replace <languageblock>
with.

> to have more than one valid language inside a problem? Any examples? We

Well as I said in the bug. I think <languageblock> is inherently a
broken design. And we need to rethink it, because of the failings you
have and continue to enumerate. Thus I agree <languageblock> is broken
and will need a redesign to fix, thus my suggestion of a
<translated> tag and it's design. I'm looking for feedback on
<translated>'s design so we don't have to do this again.

> (user pref, browser lang., etc.)?

In all but one case it is listed in a preferential order. The case
that is doesn't preserve ordering happens to be <languageblock>.  Thus
my comments on 4816. I agree this unorderedness is useless and causes
things to be hard to use and needs to be changed.

> it seems that the second prefered browser language has higher priority

<languageblock> doesn't work correctly, it's likely to work completely
randomly since as I have said (now multiple times and locations) that
it doesn't respect the ordering heirarchy.

> his course, but doesn't know if the author has used <translated> or

<languageblock> needs to die. We can do this in several ways. One idea
is to make it so that any new problems that attempt to used
<languageblock> are unpublishable thus forcing any new problems that
get generated to only use the newer tag.

Another idea, if we want to be even more harsh we can make even
published problems send error messages to authors (bombs) to try to
get them to update things sooner.

> <translated>? (One of the tags nested into the other one)

No I want one translating solution, as we all seem to agree that
<languageblock> is dysfuntional lets eliminate it.

> what occasion. Documentation is necessary.

Yes.

> e.g. German and English?  Currently, only one language could be choosen

Yes. Please file this enhancement request in bugzilla.

> used? Search and metadata both don't provide this information.

Well hopefully once we agree on a design everything will migrate to
<translated> and it won't be a concern.

Also I don't want CCs to _ever_ worry about the internal design of a
problem.  

And the only reason you care rght now is cause <languageblock> is
dysfuntional.

> (Already discussed before)

Yep. Please file this as an enhancement request.

> <languageblock>/<translated> is too complicated and impractical.

I'm curious as to what aspect is 'too complicated and impractical' ?

Can you give an example where it is? Possibly we can refine the
<translated> idea in a way where it ceases to be too complicated and
impractical.

> The

I think what you'd really prefer is c) &  d)

c) a ordered list of languages in preferential order
 &languages() would return  a list in order of preference
For instance if you had the course set to 'de', the user set to 'es'
 and the browser set to 'de' and 'en' it would return the list

('de','es','en')

d) a functional the picks the best lanuage out of a list and returns
it (or 'none' if no language is best)

For example if you had the the course set to 'de', the user set to
'es' and the browser set to 'de' and 'en' and did this call:

&pick_best_language(['es','de','en']) it would return 'de'

if you made this call

&pick_best_language(['ru','lv']) it would return 'none'

> - Do we really need <languageblock>?

I don't think it's design is salvagable and I think it should be
removed. Thusly, No.

> expected from <languageblock>.

Exactly, that is why I proposed it as a replacement.

> functionality for LON-CAPA problems.

Does 'some enhancements' mean do these 3 things:
1. eliminate <languageblock>
2. implement something like <translated>
3. implement a funtion to get the ordered list of desired languages
?

Or is there more that needs to be done that you see right now?

-- 
[email-masked]   0-7-0-9-27,137