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

[Guy Albertelli II]

Hi Stefan,

> > 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?

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


>   - The structure is fine - just what we need
>   - 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.



> <languageblock>
>   - Bug?: <languageblock> sometimes provides different language
> depending on where it is used: a) inside scriptblock with &xmlparse b)
> 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
> <languageblock> as it had the functionality of <translated>?

<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.



>   - 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...

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.



>   - 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.)?

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.


>   - 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.

<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.


> <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>?

<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.

>   - 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)

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

>   - Authors need to know which one of these two tags they should use for
> what occasion. Documentation is necessary.

Yes.

> 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.

Yes. Please file this enhancement request in bugzilla.

>   - How can I find out, which kind (<languageblock> or <translated>) is
> 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.


> New function to access valid language during runtime
> (Already discussed before)

Yep. Please file this as an enhancement request.

> 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.

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
> 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>).

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'




> 
> 
> Summary:
> - Do we really need <languageblock>?

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


> - <translated> offers the functionality which is needed and which we
> expected from <languageblock>.

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

> - Some enhancements are necessary to reach full multilingual
> 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?

-- 
guy@albertelli.com   0-7-0-9-27,137