Moodle

move login instructions to language files

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Won't Fix
  • Affects Version/s: 1.5.3
  • Fix Version/s: None
  • Component/s: Authentication
  • Labels:
    None
  • Environment:
    All
  • Affected Branches:
    MOODLE_15_STABLE

Description

The instructions for users when using external authentication, for example, pop3, are entered in a small textarea input field. This is ok when a single language is dealt with but becomes a headache in multilingual setting. Even for a single language, editing longer text in a small field is uncomfortable.

It might be a good idea to move the instructions into language files, setting the default string to empty (to match the current situation). If the local language extensions are implemented, modifying these for each site will become trivial.

Issue Links

Activity

Hide
Séverin Terrier added a comment -

I think this one can be closed : done in later versions...

Show
Séverin Terrier added a comment - I think this one can be closed : done in later versions...
Hide
Robert Brenstein added a comment -

Sorry, no, not closed but changed indicating that Moodle versions 1.8 and 1.9 are also affected. What has changed is that the field (now referred to as auth_instructions) is moved to the common area of user authentication. It is bigger, however, it is still too small for dealing with multi-lingual content – try working with the standard instructions in 3 different languages there . A simple remedy is to make the field bigger. A better solution is to make auth_instructions a string in language files, so it can be more cleanly handled for multiple languages. The .local language files have been implemented in the meantime, which makes handling the latter option a no brainer.

An alternative could be a combo approach. When the login page is loaded, the program checks whether the auth_instructions field is filled, if yes, it uses it. If not, it checks if string auth_instructions in the current language is not empty. If not, it uses it. This would probably be most optimal approach, requiring little extra documentation.

Show
Robert Brenstein added a comment - Sorry, no, not closed but changed indicating that Moodle versions 1.8 and 1.9 are also affected. What has changed is that the field (now referred to as auth_instructions) is moved to the common area of user authentication. It is bigger, however, it is still too small for dealing with multi-lingual content – try working with the standard instructions in 3 different languages there . A simple remedy is to make the field bigger. A better solution is to make auth_instructions a string in language files, so it can be more cleanly handled for multiple languages. The .local language files have been implemented in the meantime, which makes handling the latter option a no brainer. An alternative could be a combo approach. When the login page is loaded, the program checks whether the auth_instructions field is filled, if yes, it uses it. If not, it checks if string auth_instructions in the current language is not empty. If not, it uses it. This would probably be most optimal approach, requiring little extra documentation.
Hide
Iñaki Arenaza added a comment -

Robert,

I have just committed a fix for MDL-19053, which means you can now use the HTML editor to edit the instructions.

This means you can have a full-screen area to edit your instructions if you want, and also that you can use the multilang filter more easily to have your instructions in as many languages as you want.

Would that be enough for you? (so we could close the bug if it is).

Saludos,
Iñaki.

Show
Iñaki Arenaza added a comment - Robert, I have just committed a fix for MDL-19053, which means you can now use the HTML editor to edit the instructions. This means you can have a full-screen area to edit your instructions if you want, and also that you can use the multilang filter more easily to have your instructions in as many languages as you want. Would that be enough for you? (so we could close the bug if it is). Saludos, Iñaki.
Hide
Robert Brenstein added a comment -

I actually do not use the html editor as a rule (partly because I used Mac and there were compatibility problems, and partly because I prefer to work directly in html), but I guess this will solve the issue for most people. Enlarging the htmlarea when html editor is not in use should be easy to include as well, I guess.

Show
Robert Brenstein added a comment - I actually do not use the html editor as a rule (partly because I used Mac and there were compatibility problems, and partly because I prefer to work directly in html), but I guess this will solve the issue for most people. Enlarging the htmlarea when html editor is not in use should be easy to include as well, I guess.
Hide
Iñaki Arenaza added a comment -

Hi again Robert (and sorry for the long delay),

right now the (nom-html) textarea is 15 lines high and 60 columns width. I'd say this is plenty for most uses (even multi-language instructions), but how big would you say it should be when not using the html editor?

Saludos,
Iñaki.

Show
Iñaki Arenaza added a comment - Hi again Robert (and sorry for the long delay), right now the (nom-html) textarea is 15 lines high and 60 columns width. I'd say this is plenty for most uses (even multi-language instructions), but how big would you say it should be when not using the html editor? Saludos, Iñaki.
Hide
Michael de Raadt added a comment -

Thanks for reporting this issue.

We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

Michael d;

lqjjLKA0p6

Show
Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d; lqjjLKA0p6
Hide
Michael de Raadt added a comment -

I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.

Show
Michael de Raadt added a comment - I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.

Dates

  • Created:
    Updated:
    Resolved: