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

[Stefan Bisitz]

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