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

[Stefan Bisitz]

Guy Albertelli II 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.)

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

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

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.


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

I found what went wrong. The following problem now displays the same
language in both cases. They were different before I eliminated the
escape character "\" before the """ at include and exclude in the
xmlparse. Somewhere is an example where the "\" were used (I guess to
avoid conflicts with the "'" surrounding the xmlparse content). Now it
works fine.
---- start ----
<problem>

<script type="loncapa/perl">
$text = &xmlparse('
<languageblock include="de">Deutsch</languageblock>
<languageblock exclude="de">English</languageblock>
');
</script>

<startouttext />
$text
<br />
<languageblock include="de">Deutsch</languageblock>
<languageblock exclude="de">English</languageblock>
<endouttext />

</problem>
---- end ----


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

This would make a change less complicated.


> > Don't we all use
> > <languageblock> as it had the functionality of <translated>?
>
> [...]
> 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.
> [...]
> 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.

Ok, let's replace it. Peter and I discussed <translated> and found it to
be fitting.


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


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

Better not. Maybe at a later time when we expect that everybody has
changed all the problems which used <languageblock>.


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

Ok.


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

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.


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

Our aim is that we are able to create multilingual problems with ALL
kinds of LON-CAPA answerblocks. Especially, this means that we need an
easy way to make problems multilingual with answerblocks which don't
allow the usage of <translated>, e.g. optionresponse. Until now, we
created the neccessary contents which depend on the language in the
scriptblock, stored them in variables and used them in the answerblock.

In other words, we found out that we need a function that helps the
author to fill variables depending on the same language which
<translated> would use. the following function is a result of this
thoughts. Any other solutions for these kind of answerblocks are welcome.


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

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

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

Yes, and there is more, like the mentioned enhancment for more than one
language in the meta data.


And, at least, there is one more big thing that has to be discussed. We
should start a new and separate discussion:
- Author #1 creates a problem in language 1
- Author #2 likes this problem and wants to use it, but in language 2
- Author #3 likes this problem and wants to use it, but in language 3

Different solutions cause an unwanted splitting:
a) Open XML code
Author #2 copies the problem, creates a new problem with same content
but with language 2 and publishes it as a new problem. Author #3 does
the same with language 3
-> Three published versions of one problem

b) Closed XML code
Author #2 "steals" the content from the screen and creates a new problem
but with language 2. Same with Author #3
-> Three slightly different, published versions of one problem

c) Co-Author
c1) Author #2 and Author #3 become Co-Author of Author #1, translate the
problem and republish
-> One problem with three different languages
c2) Author #1 doesn't want to allow others to be Co-Author
-> ?

c1) is prefered, of course, but I expect, that in most cases b) would be
common and a) the next.

A long time ago we talked with Gerd about this problem. The role
"librarian" seemed to be a solution. A person with this role is only
allowed to access the multilingual parts of a problem and can change
them. Big disadvantages are:
- Organization of communication between the author, the person who wants
to use the problem in a different language and the librarian (could be
supported by LON-CAPA)
- The multilingual parts of a problem need to be separated from the rest
of the problem.


That's all for now. Comments are welcome.

Stefan Bisitz