Moodle Community Sites
  1. Moodle Community Sites
  2. MDLSITE-913

Move the lang directories into one directory and give David Mudrak rights to it

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Component/s: download.moodle.org
    • Labels:
      None
    • Rank:
      25710

      Description

      Jordan can you change download.moodle.org so that

      1) All the language directories in /web/lang16 web/lang20 etc are moved into /web/lang/1.6 and /web/lang/2.0 etc.
      2) Apache redirects are put in for all those moved dierectories
      3) David has rights to manage that whole lang directory

      Thanks!

        Activity

        Martin Dougiamas created issue -
        Hide
        David Mudrak added a comment -

        Ping I will need regularly (daily, hourly - to be decided) publish ZIPs exported from AMOS. Hungry people start to call for localized 2.0 preview builds already. Are there any blockers for this?

        Show
        David Mudrak added a comment - Ping I will need regularly (daily, hourly - to be decided) publish ZIPs exported from AMOS. Hungry people start to call for localized 2.0 preview builds already. Are there any blockers for this?
        Hide
        Jordan Tomkinson added a comment -

        this has been done

        Show
        Jordan Tomkinson added a comment - this has been done
        Hide
        David Mudrak added a comment -

        We must deal with Eloy's scripts that generate ZIP files from CVS snapshots yet. Jordan, can you describe what is the physical structure of dirs involved and to what URLs/symlinks they are mapped?

        Because we must keep backwards compatibility, urls /lang15 and /lang16 must still work (without 302 redirecting, as shown today). There are Eloy's scripts that update their contents from CVS snapshots. I just realized that we do not need to symlink /lang16 to the new /langpack/1.6, in fact. Not only because lang16 is more a format than version.

        My proposal is: let us keep Eloy's scripts putting CVS snapshots into legacy /lang15 and /lang16 and let us AMOS generate all /langpack/x.x/. Moodle 2.0 will use /langpack/2.0. Moodle 1.x will still use legacy /lang16. I will improve AMOS export scripts so that they fetch /html and /doc from CVS. Therefore, fetching lang packs from /langpack/1.x could be implemented as experimental feature at MOODLE_19_STABLE, just to make use it works. We can switch later, in 1.9.9 or 1.9.10.

        The proposal should allow Moodle 2.0 packs distribution while not touching the stable branch.

        Show
        David Mudrak added a comment - We must deal with Eloy's scripts that generate ZIP files from CVS snapshots yet. Jordan, can you describe what is the physical structure of dirs involved and to what URLs/symlinks they are mapped? Because we must keep backwards compatibility, urls /lang15 and /lang16 must still work (without 302 redirecting, as shown today). There are Eloy's scripts that update their contents from CVS snapshots. I just realized that we do not need to symlink /lang16 to the new /langpack/1.6, in fact. Not only because lang16 is more a format than version. My proposal is: let us keep Eloy's scripts putting CVS snapshots into legacy /lang15 and /lang16 and let us AMOS generate all /langpack/x.x/. Moodle 2.0 will use /langpack/2.0. Moodle 1.x will still use legacy /lang16. I will improve AMOS export scripts so that they fetch /html and /doc from CVS. Therefore, fetching lang packs from /langpack/1.x could be implemented as experimental feature at MOODLE_19_STABLE, just to make use it works. We can switch later, in 1.9.9 or 1.9.10. The proposal should allow Moodle 2.0 packs distribution while not touching the stable branch.
        Hide
        Jordan Tomkinson added a comment -

        I resolved this issue last night by removing the apache redirects and using symlinks instead
        this gives http 200 on the urls and eloy's scripts still work

        with this in mind do you still want to move them out of /langpack/ back into the root of download.moodle.org ?

        Show
        Jordan Tomkinson added a comment - I resolved this issue last night by removing the apache redirects and using symlinks instead this gives http 200 on the urls and eloy's scripts still work with this in mind do you still want to move them out of /langpack/ back into the root of download.moodle.org ?
        Hide
        David Mudrak added a comment -

        Well, it depends on what the procedure of translating 1.x will be and it is something MD shall decide. I can see two options:

        • translators use only AMOS for translating strings. AMOS handles generating packs for all Moodle branches. Legacy HTML help files are still committed into CVS but translators loose access to the language root, that is strings. So they will have write access to lang/xx/help/ only, not into lang/xx/. When generating ZIPs, AMOS will attach /help/ folder from CVS snapshot for 1.x packages.
        • or, translators use AMOS for 2.x strings and CVS for 1.x strings. 1.x are not translatable via AMOS but they will appear there and once a new string is committed into 1.x CVS, it will be propagated into 2.x as well, if it should exist there.

        We can not have both CVS and AMOS for all branches, because of the following problem. If translator modifies a string in AMOS portal for Moodle 1.9 but not in CVS, it will be replaced by CVS version sometimes in the future when AMOS detects a change in that file (which may be completely different string but the patch will contain the revert).

        Show
        David Mudrak added a comment - Well, it depends on what the procedure of translating 1.x will be and it is something MD shall decide. I can see two options: translators use only AMOS for translating strings. AMOS handles generating packs for all Moodle branches. Legacy HTML help files are still committed into CVS but translators loose access to the language root, that is strings. So they will have write access to lang/xx/help/ only, not into lang/xx/. When generating ZIPs, AMOS will attach /help/ folder from CVS snapshot for 1.x packages. or, translators use AMOS for 2.x strings and CVS for 1.x strings. 1.x are not translatable via AMOS but they will appear there and once a new string is committed into 1.x CVS, it will be propagated into 2.x as well, if it should exist there. We can not have both CVS and AMOS for all branches, because of the following problem. If translator modifies a string in AMOS portal for Moodle 1.9 but not in CVS, it will be replaced by CVS version sometimes in the future when AMOS detects a change in that file (which may be completely different string but the patch will contain the revert).
        Hide
        David Mudrak added a comment -

        Adding Martin and Koen to hear their opinions on the procedures described above.

        Show
        David Mudrak added a comment - Adding Martin and Koen to hear their opinions on the procedures described above.
        Hide
        Koen Roggemans added a comment -

        On first reading I would go for solution two for simplicity sake. 1.9 interface and procedure for 1.9 and below, a new procedure for 2.0 and above. For solution one you still have to maintain a stable 1.9 branch and CVS rights too, so you need both complete systems (AMOS and CVS) to be able to translate 1.x: that is more complicated.

        Show
        Koen Roggemans added a comment - On first reading I would go for solution two for simplicity sake. 1.9 interface and procedure for 1.9 and below, a new procedure for 2.0 and above. For solution one you still have to maintain a stable 1.9 branch and CVS rights too, so you need both complete systems (AMOS and CVS) to be able to translate 1.x: that is more complicated.
        Hide
        Martin Dougiamas added a comment -

        I agree with you Koen. Solution 2 seems like it will be easier for people to understand: new procedure for a new version.

        Show
        Martin Dougiamas added a comment - I agree with you Koen. Solution 2 seems like it will be easier for people to understand: new procedure for a new version.
        Hide
        Jordan Tomkinson added a comment -

        Can we resolve this issue yet?

        Show
        Jordan Tomkinson added a comment - Can we resolve this issue yet?
        Hide
        David Mudrak added a comment -

        Yup, resolving. Thanks.

        Show
        David Mudrak added a comment - Yup, resolving. Thanks.
        David Mudrak made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Martin Dougiamas made changes -
        Workflow jira [ 36340 ] SITES Full Workflow [ 126226 ]
        Martin Dougiamas made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development