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

[Guy Albertelli II]

Hi Stefan,

> Ok, fine. This structure looks like the new solution for multilingual
> problem texts. See below some more explanations to the still existing
> constraints for answerblocks.

Okay.

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

Will do.


> Try to create a multilingual problem with optionresponse. The optionlist
> must be created in the scriptblock with the use of xmlparse. Long and
> hard-to-read lines must be used.

Ugh. Yep optionresponse will be poor, I'd suggest using
<matchresponse> instead, it's not as compact an on screen display but
it's xml structure will make translation support easier.

I think <optionresponse> is the only one that is hard with respect to
this, right?


> > > 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'
> 
> Compared to what we really need (see explanation above), a or d seems to
> be enough and best fitting.

Hmm, a is a simplifed form of c, if I have c I can get a, if I have a
I can't get c.

my ($best) = &languages();
my @all = &languages();


> But please let's keep the function name short(er), e.g. get_lng()

I really like decriptive function names, it makes figuring out what's
going on easier. I'll try to make then not to wordy though.

But I think the &languages() function should be able to do it all.

my $best = &languages(); # gets you the language the user most wants
my @all  = &languages();    # gets you all languages the user likes
my $best_available = &languages(['en','de','ru']);
                           # gets you the best match out of the list
			   # you have available, if none are liked, 
			   # $best_available will be undef
my @doable = &languages(['en','de','ru']);
                           # gets you all languages they like out of
			   # the ones available, if none are good
			   # @doable will be undef

In summary

1. deprecate <languageblock>
2. implement <translated>
3. implement &languages()
4. investigate changing <optionresponse> to be easier in a translated
   context.
5. metadata needs to allow multiple languages per resource

(Defering the authoring question to a separate email)
-- 
guy@albertelli.com   0-7-0-9-27,137