mahara-contributors team mailing list archive

[Dominique-Alain JAN <944074@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Branch 1.4
Branch main

>From Mahara 1.2 the mechanism to get display other language than English
has changed. Previously localized strings where placed in different
parts of the core code, together with the /lang/en.utf8 folders.

For now, the lang menu is showed only if one or mere xx.utf8 folders are
found in the maharadata/langpack folder. And after a discussion about
this with François I agree this is fine.

Normally, when a non-English language is selected by the admin or the
user, it seems to me, that Mahara first looks into the core lang folders
for the appropriate xx.utf8 folders and if not found, goes into the
langpack afterwards.

With some plugins this works fine (e.g., CPDS) and for example French
strings are displayed from the fr.utf8 folders embeded in the plugin
folder. With some others (embdly, externsource, ldap, ...) this doesn't
work. To get the French translation, the admin has to move the fr.utf8
from the core plugins folders and place them into the langpack folders
in the maharadata.

I don't understand that the behaviour is different from one plugin to
another.

Moreover, I would propose that the multilingual mechanist become the
following:

1) I can cope with the obligation to create a xx.utf8 folder in the
maharadata/langpack folder to avoid having a list of undesired languages
in the language menu. This gives system admin a way to control languages
displayed on the platform.

For each string to be displayed:

2) Mahara gets the user/system selected language (xx)
3) Mahara first looks into the langpack/xx.utf8 folder. If the folder is found, Mahara uses all the strings of these files to display information
4) If the string is not found, Mahara looks into the core lang/xx.utf8 folders to find it, if found, it displays the information
5) If the string is not found, Mahara looks into the langpacks/en.utf8 folder
6) If the string is not found, Mahara looks into the core lang/en.utf8 folder
7) If the string is not found, Mahara displays an error with the name of the string? (But this should never happen).

That way:

A) developers can offer localised versions of their plugin without
giving more work to the system admin for moving files from the plugin to
the maharadata/langpack

B) Wether admins want override a translation or the en.utf8 strings,
they can by adding xx.utf8 or en.utf8 folders into the langpack folder.

Maybe a discussion could start here about this (bug report and feature request)
-dajan

** Affects: mahara
     Importance: Undecided
         Status: New

** Description changed:

  Branch 1.4
  Branch main
  
  From Mahara 1.2 the mechanism to get display other language than English
  has changed. Previously localized strings where placed in different
  parts of the core code, together with the /lang/en.utf8 folders.
  
- For now, the lang menu is showned only if one or mere xx.utf8 folders
- are found in the maharadata/langpack folder. And after a discussion
- about this with François I agree this is fine.
+ For now, the lang menu is showed only if one or mere xx.utf8 folders are
+ found in the maharadata/langpack folder. And after a discussion about
+ this with François I agree this is fine.
  
  Normally, when a non-English language is selected by the admin or the
  user, it seems to me, that Mahara first looks into the core lang folders
  for the appropriate xx.utf8 folders and if not found, goes into the
  langpack afterwards.
  
  With some plugins this works fine (e.g., CPDS) and for example French
  strings are displayed from the fr.utf8 folders embeded in the plugin
  folder. With some others (embdly, externsource, ldap, ...) this doesn't
  work. To get the French translation, the admin has to move the fr.utf8
  from the core plugins folders and place them into the langpack folders
  in the maharadata.
  
  I don't understand that the behaviour is different from one plugin to
  another.
  
  Moreover, I would propose that the multilingual mechanist become the
- following :
+ following:
  
  1) I can cope with the obligation to create a xx.utf8 folder in the
  maharadata/langpack folder to avoid having a list of undesired languages
  in the language menu. This gives system admin a way to control languages
  displayed on the platform.
  
- For each string to be displayed :
+ For each string to be displayed:
  
- 2) Mahara get  the user/system selected language (xx)
+ 2) Mahara gets the user/system selected language (xx)
  3) Mahara first looks into the langpack/xx.utf8 folder. If the folder is found, Mahara uses all the strings of these files to display information
  4) If the string is not found, Mahara looks into the core lang/xx.utf8 folders to find it, if found, it displays the information
  5) If the string is not found, Mahara looks into the langpacks/en.utf8 folder
  6) If the string is not found, Mahara looks into the core lang/en.utf8 folder
- 7) If the string is not found, Mahara displays an error with the name of the string? (but this should never happen).
+ 7) If the string is not found, Mahara displays an error with the name of the string? (But this should never happen).
  
- That way :
+ That way:
  
  A) developers can offer localised versions of their plugin without
  giving more work to the system admin for moving files from the plugin to
  the maharadata/langpack
  
- B) Wether admins want  override a translation or the en.utf8 strings,
- they can by adding  xx.utf8 or en.utf8 folders into the langpack fodler.
+ B) Wether admins want override a translation or the en.utf8 strings,
+ they can by adding xx.utf8 or en.utf8 folders into the langpack fodler.
  
  Maybe a discussion could start here about this (bug report and feature request)
  -dajan

** Description changed:

  Branch 1.4
  Branch main
  
  From Mahara 1.2 the mechanism to get display other language than English
  has changed. Previously localized strings where placed in different
  parts of the core code, together with the /lang/en.utf8 folders.
  
  For now, the lang menu is showed only if one or mere xx.utf8 folders are
  found in the maharadata/langpack folder. And after a discussion about
  this with François I agree this is fine.
  
  Normally, when a non-English language is selected by the admin or the
  user, it seems to me, that Mahara first looks into the core lang folders
  for the appropriate xx.utf8 folders and if not found, goes into the
  langpack afterwards.
  
  With some plugins this works fine (e.g., CPDS) and for example French
  strings are displayed from the fr.utf8 folders embeded in the plugin
  folder. With some others (embdly, externsource, ldap, ...) this doesn't
  work. To get the French translation, the admin has to move the fr.utf8
  from the core plugins folders and place them into the langpack folders
  in the maharadata.
  
  I don't understand that the behaviour is different from one plugin to
  another.
  
  Moreover, I would propose that the multilingual mechanist become the
  following:
  
  1) I can cope with the obligation to create a xx.utf8 folder in the
  maharadata/langpack folder to avoid having a list of undesired languages
  in the language menu. This gives system admin a way to control languages
  displayed on the platform.
  
  For each string to be displayed:
  
  2) Mahara gets the user/system selected language (xx)
  3) Mahara first looks into the langpack/xx.utf8 folder. If the folder is found, Mahara uses all the strings of these files to display information
  4) If the string is not found, Mahara looks into the core lang/xx.utf8 folders to find it, if found, it displays the information
  5) If the string is not found, Mahara looks into the langpacks/en.utf8 folder
  6) If the string is not found, Mahara looks into the core lang/en.utf8 folder
  7) If the string is not found, Mahara displays an error with the name of the string? (But this should never happen).
  
  That way:
  
  A) developers can offer localised versions of their plugin without
  giving more work to the system admin for moving files from the plugin to
  the maharadata/langpack
  
  B) Wether admins want override a translation or the en.utf8 strings,
- they can by adding xx.utf8 or en.utf8 folders into the langpack fodler.
+ they can by adding xx.utf8 or en.utf8 folders into the langpack folder.
  
  Maybe a discussion could start here about this (bug report and feature request)
  -dajan

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
https://bugs.launchpad.net/bugs/944074

Title:
  Problem in finding translations in third party plugins

Status in Mahara ePortfolio:
  New

Bug description:
  Branch 1.4
  Branch main

  From Mahara 1.2 the mechanism to get display other language than
  English has changed. Previously localized strings where placed in
  different parts of the core code, together with the /lang/en.utf8
  folders.

  For now, the lang menu is showed only if one or mere xx.utf8 folders
  are found in the maharadata/langpack folder. And after a discussion
  about this with François I agree this is fine.

  Normally, when a non-English language is selected by the admin or the
  user, it seems to me, that Mahara first looks into the core lang
  folders for the appropriate xx.utf8 folders and if not found, goes
  into the langpack afterwards.

  With some plugins this works fine (e.g., CPDS) and for example French
  strings are displayed from the fr.utf8 folders embeded in the plugin
  folder. With some others (embdly, externsource, ldap, ...) this
  doesn't work. To get the French translation, the admin has to move the
  fr.utf8 from the core plugins folders and place them into the langpack
  folders in the maharadata.

  I don't understand that the behaviour is different from one plugin to
  another.

  Moreover, I would propose that the multilingual mechanist become the
  following:

  1) I can cope with the obligation to create a xx.utf8 folder in the
  maharadata/langpack folder to avoid having a list of undesired
  languages in the language menu. This gives system admin a way to
  control languages displayed on the platform.

  For each string to be displayed:

  2) Mahara gets the user/system selected language (xx)
  3) Mahara first looks into the langpack/xx.utf8 folder. If the folder is found, Mahara uses all the strings of these files to display information
  4) If the string is not found, Mahara looks into the core lang/xx.utf8 folders to find it, if found, it displays the information
  5) If the string is not found, Mahara looks into the langpacks/en.utf8 folder
  6) If the string is not found, Mahara looks into the core lang/en.utf8 folder
  7) If the string is not found, Mahara displays an error with the name of the string? (But this should never happen).

  That way:

  A) developers can offer localised versions of their plugin without
  giving more work to the system admin for moving files from the plugin
  to the maharadata/langpack

  B) Wether admins want override a translation or the en.utf8 strings,
  they can by adding xx.utf8 or en.utf8 folders into the langpack
  folder.

  Maybe a discussion could start here about this (bug report and feature request)
  -dajan

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/944074/+subscriptions