Change frontend and editor path


At the moment, frontend path uses /a, and alpha editor uses /app, as part of this change:

Scope changes

  • Changed new glossary path from /glossary/{id} to /glossary?locale={localeid}

    • There is no glossary id since we only have a global glossary

    • Discussed 1/Sep/16 by damason, sflanigan

  • Added Requirements section.

    • In yesterday's meeting, we discussed several requirements, but they were not written down.

    • Checked with aeng about what we discussed for redirects.


  • "Try the new alpha editor" button in old editor still opens the new editor.

  • Opening a bookmark to the previous location of the alpha editor should show a 404 page.

    • There was discussion of a link from the 404 page to the new alpha editor path, but no one wrote it down. No one will remember by the time it is being tested, so I guess I should just add this if I feel like it.

  • Profile and glossary pages are not deployed yet so no redirect is needed.

New paths to implement


  • currently


  • currently


  • currently

  • document should be standard url encoded, but / characters can be included literally. Spaces, percentage sign, comma, quotes, apostrophe, semicolon, question mark, etc. will still need to be encoded, similar to github. e.g.

Technical notes

This will require some server-side rules, similar to the ones we use on the project pages (which use crossroads.js for client-side routing):


Sean Flanigan
July 27, 2016, 10:59 AM

So, in terms of keeping URL compatibility, if the browser asks for /app, we won't know if the user expects the alpha editor (old bookmark) or frontend (new bookmark)? How's that going to work?

If we want to change the URLs, I think we might have to choose something else.

But just because frontend and editor are sharing code doesn't mean their URLs should share a prefix. What's the reason for changing the URLs?

David Mason
July 27, 2016, 11:17 AM

There are a few risks we should make sure we deal with before and during implementation of this:

  • Broken bookmarks by users.

    • This is only an issue for the alpha editor since the other parts are not deployed to production yet.

    • May be able to mitigate with a redirect, as long as the paths do not conflict.

  • Broken internal links.

    • Need to review/test thoroughly for links to all the frontend pieces.

    • Alpha editor is only linked from the old editor, so it should be a simple change.

  • Broken tests - e.g. functional tests that navigate to frontend pages.

    • Should be easy to fix if we are using page objects properly.

    • Should be easy to fix if we have inadequate tests :S

  • Does this change fit with our overall strategy for Zanata's URLs?

    • Team, especially UX, should collaborate on this aspect.

Alex Eng
July 28, 2016, 11:07 AM

frontend uses /a at the moment. The idea was to have at least js modules under /app

So Alpha editor will be /app/editor where /app will be used for frontend.

frontend url (/a) - is not deployed to production yet, so there will be no impact on users.

editor url (/app) - Personally, I don't think changing the url for the will have huge impact. (How do you know if no one has bookmarked it? well.. how do we know if anyone had bookmarked it?), but being a professional software engineer, then we have to think of every possible scenario, even just a single user. But do we want to? I think it will benefit more to the users if we use the time discussing this topic to actually start implementing features in alpha editor.

Broken tests: Should be fix as part of this. (we can merge PR which is not green in jenkins?)

Again, that's my opinion.

Sean Flanigan
August 18, 2016, 12:49 PM

After a bit of a discussion with and , I think we agree that if we change the URLs, we only want to do it once, so we should think about what the URLs would look like ideally (without our current technology choices deciding the URLs for us).

I'm thinking something like:


  • currently /a/#profile or something


  • currently /a/#glossary or something


  • document is standard url encoded. (spaces and percentage sign will still need to be encoded, similiar with github)

  • currently /app/something

So, no use of prefixes like /a/ and /app/. This will require some server-side rules, similar to the ones we use on the project pages (which use crossroads.js for client-side routing):

Those URLs are just off the top of my head. Obviously we will need to put some thought into choosing good long-term URLs for these pages.

Ready for Release


David Mason


Alex Eng



Tested Version/s


Story Points


Time tracking


Time remaining




Fix versions