Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URL policy #27

Closed
stuartpb opened this issue Jun 9, 2015 · 1 comment
Closed

URL policy #27

stuartpb opened this issue Jun 9, 2015 · 1 comment
Milestone

Comments

@stuartpb
Copy link
Member

stuartpb commented Jun 9, 2015

URLs should be as widely-applicable as possible, with as many components as possible removed that refer to specific contexts (such as referrers and locales), so long as visiting the simplified URL still results in the desired page.

In the event that certain components can't be removed without breaking the page (such as adobe.com), the used components should be as generic as possible (ie. using those components that would be presented when reaching that page from the root domain). Where generic values aren't possible but specific universal values are, they should use the most common specific instance (eg. 37signals accounts using Basecamp's Launchpad) or closest to the origin / most targeted market (so eg. if Pottermore required a locale, it would use en-GB).

(In the event of ties, English and specifically en-US wins, following the same logic as #12.)

In the event that there is no acceptable universally-usable value, the component should be variable-concatenated out (ie. the way usernames in URLs are).

@stuartpb
Copy link
Member Author

Closing in favor of the project wiki Style Guide section on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant