Uploaded image for project: '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
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: download.moodle.org
    • Labels:
      None

      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!

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            mudrd8mz David Mudrák 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
            mudrd8mz David Mudrák 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
            jtomkinson Jordan Tomkinson added a comment -

            this has been done

            Show
            jtomkinson Jordan Tomkinson added a comment - this has been done
            Hide
            mudrd8mz David Mudrák 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
            mudrd8mz David Mudrák 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
            jtomkinson 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
            jtomkinson 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
            mudrd8mz David Mudrák 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
            mudrd8mz David Mudrák 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
            mudrd8mz David Mudrák added a comment -

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

            Show
            mudrd8mz David Mudrák added a comment - Adding Martin and Koen to hear their opinions on the procedures described above.
            Hide
            koen 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 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
            dougiamas 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
            dougiamas 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
            jtomkinson Jordan Tomkinson added a comment -

            Can we resolve this issue yet?

            Show
            jtomkinson Jordan Tomkinson added a comment - Can we resolve this issue yet?
            Hide
            mudrd8mz David Mudrák added a comment -

            Yup, resolving. Thanks.

            Show
            mudrd8mz David Mudrák added a comment - Yup, resolving. Thanks.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: