Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Improving English language strings

From MoodleDocs

Changing or creating a new lang string?

New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in master, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but is is considered to be the lang pack bug.

When a new string is introduced, the old one should be deprecated or removed so that unused strings do not accumulate.

Basically I see it as (for master only):
  1. Any change is allowed (semantical or structural). It does not have sense to keep the old string because there won't be use for it when the new Moodle version is released. So we can forget about the old one 100%. Of course if the string is radically different, then it may have sense to create a new, completely different string (and proceed with next point).
  2. If for any reason we stop using any string (because a feature is out or because we have decided to create a new different string instead of change existing)), then:
    • if the old string is really specific (not suitable for reuse) we can safely proceed to delete it,.
    • If the string belongs to a plugin, IMO we can also proceed to delete it (reuse of plugin strings should not be allowed).
    • But, if the string is generic (may be reused) and it's not part of a plugin then the string must be deprecated.
And, for stables, only small semantical changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string.
--Eloy Lafuente (stronk7) (talk) 19:48, 5 March 2015 (AWST)

Using en_fix versus changing strings in a patch

  • en_fix is mainly for fixing the English - typos, incorrect spelling or grammar - and not for important terminology changes
  • UI string changes can require Behat tests to be fixed

en_fix and different versions

Previously AMOS auto-merged en_fix strings to different versions (as for all other languages). However this behaviour was changed in April 2016. Thus, from now on:

  • For typos and spelling mistakes that should be applied to all branches, it is necessary to explicitly propagate the change to all supported versions (e.g. DEV, 3.0 and 2.9 though it doesn't matter if all checkboxes are left ticked)
  • UI string changes should be committed into DEV only without propagation.