Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.There are several places in the UI where we refer to the "system paths" of Drupal. Most of the time (in 6 and in the past) these are referred to as "system paths".
(See http://drupal.org/node/87777 for details on the use of the different phrases)
This patch standardizes the UI on "system path"
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 182991-internal-path_21.patch | 24.23 KB | scor |
| #17 | 182991-internal-path_17.patch | 24.09 KB | scor |
| #16 | 182991-internal-path.patch | 21.29 KB | keith.smith |
| #3 | system_path_standardization4.patch | 7.68 KB | scor |
| #2 | system_path_standardization3.patch | 7.69 KB | scor |
Comments
Comment #1
scor CreditAttribution: scor commentedI've identified more of these. I've added them to greggles' patch.
Comment #2
scor CreditAttribution: scor commentedfixed a rejected hunk and rerolled!
Comment #3
scor CreditAttribution: scor commentedneeded a reroll.
it's actually a documentation issue.
Comment #4
JirkaRybka CreditAttribution: JirkaRybka commentedThis applies cleanly, doesn't break anything (I tried a clean install with the patch applied and various administrative pages), and helps us to more consistency. The issue linked above (especially comments around #9 - http://drupal.org/node/87777#comment-454831 ) gives enough background.
Comment #5
Gábor HojtsyI don't agree 'system path' makes it better at all. What system? File system? Why not standardize on "Drupal path"? Honestly all of "Drupal path" (= the path to Drupal on the file system?), "internal path" (internal to what?) and "system path" (= path on the file system?) feels possibly ambiguous to me. Anyway, I don't think standardizing on "system path" gets us forward, it sounds too external to Drupal.
Comment #6
gregglesI've listed the places that are impacted by this broken down by where the strings are shown to users.
*Admin pages:
Individual Block configuration
Locale administration
Menu admin
*Schema help texts:
Locale install
Statistics installation
*"Everyday site visitor who can only create content visible pages"
None
As we initially discussed this in irc I remember grepping through the source code to see which was more common between all these variations and then deciding to standardize on the most common one.
All of the places where those strings are shown to users I think it's fair to say that the user knows what "Drupal" is and indeed may be confused about a "system" path. However, people who won't necessarily know what Drupal is are distribution users. The idea of throwing in "Drupal" to describe something in general feels like a cop-out. It also means that the companies who create productized specialized distributions have to to either 1) patch core to remove these 2) educate their users "We know that we told you this was the CivicSpace/RainCity/Bryght/Acquia whatever distribution, but when you see 'Drupal' in the interface that's the same thing". Neither of those solutions sounds good to me, but I guess that's not my argument to make since I don't have a distro.
Comment #7
scor CreditAttribution: scor commentedIt's fair to say that "system path" can be ambiguous, but there seem to be no better wording, and it is already used in most of the UI.
I think the current inconsistent situation is more ambiguous than anything. Is it less ambiguous to have other expression such as "internal path" and "Drupal path" to actually talk about the same thing as "system path"? Once a new user figures out what "system path" means, he then have to figure out what "internal path" and "Drupal path" are. Intuitively, he would not think that all these term refer to the same thing.
Let "system path" be part of the Drupal learning curve, and let's keep the UI consistent.
Comment #8
Gábor HojtsyTo me, 'internal path' sounds like much better if we'd like to avoid using Drupal in the name. As said, 'system path' sounds external to Drupal IMHO.
Comment #9
scor CreditAttribution: scor commentedcurrently, "internal path" is only used twice: in the schema of statistics module, and in menu.admin.inc.
If there is support for "internal path", I can roll a patch. Let's get more opinions first.
Comment #10
scor CreditAttribution: scor commentedthere isn't much time left to decide on that if the rc1 is to be released in the next few days...
Comment #11
keith.smith CreditAttribution: keith.smith commentedTo quote Gábor from http://lists.drupal.org/pipermail/development/2007-December/027977.html: "RC1 is string freeze, so whatever needs modifications in the strings is generally postponed to Drupal 7."
Comment #12
Freso CreditAttribution: Freso commentedFWIW, my vote is for "Drupal path". "Drupal path" clearly states that it's the path which Drupal recognises - it doesn't have anything to do with the file system, the web server, PHP's path,
$PATH, or any other such thing "outside" Drupal. Also, any string mentioning these paths should be admin-centric, and there shouldn't be a need to hide the "Drupal factor" from such fellows, IMHO. (And if there really is a need to hide this, there are plenty of options of overriding strings through various means.)But +1 to standardising on one term for one "idea".
Comment #13
gregglesI assume this needs work now.
Comment #14
lilou CreditAttribution: lilou commentedComment #15
lilou CreditAttribution: lilou commentedsee also : #98905: Remove the word 'Drupal' from interface
Comment #16
keith.smith CreditAttribution: keith.smith commentedThe attached patch changes "Drupal path", "system path", and friends to a hopefully-consistent "internal path", as Gábor suggested in #8.
This standardizes an important piece of terminology, and removes an instance where we refer to "Drupal" inside the interface (which may not be ideal for white-label applications).
I am hopeful that I got most of them, including references in code comments, but obviously could have easily missed some. This patch should handle those instances revealed by a grep for "system path" and "Drupal path" , however.
Comment #17
scor CreditAttribution: scor commentedfound 4 more instances to be fixed. later we might also want to standardize on path vs URL, but let's not hijack this thread for now.
Comment #18
scor CreditAttribution: scor commentedupdating title
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedI know I'm coming into this late but the recent review just flagged me.
Neither of these makes sense to me. This makes more sense:
And
is better as
So instead of "internal" we should use "request" and restructure the sentence to fit that word. I don't know what an internal path is; it seems mysterious and hidden from user view but a request path is one that is being requested for the action.
Comment #20
alexanderpas CreditAttribution: alexanderpas commentedinternal path should be used for user facing stuff, drupal path... request path, system path and internal path should be used in the documentation where appropriate.
internal path is a path pointing to a destination (node, etc...) within the site.
request path can be used for RPC etc.
Comment #21
scor CreditAttribution: scor commentedI disagree with #19 first statement. Here we purposely check whether it's an alias in which case we set $_GET['q'] to the internal path. See drupal_init_path() and drupal_get_normal_path(): "Given a path alias, return the internal path it represents."
The second fix in #19 makes sense. I updated the patch. The patch also adds one fix 'normal path' -> 'internal path'.
By the way, 'normal path' was never suggested before. It might make sense to consider it in the discussion.
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedI disagree with the word internal for this documentation. The word internal means that the user will never see the object because it isn't accessible externally and that isn't true for the paths that are being documented. Two references for the word internal http://dictionary.reference.com/search?q=internal and http://dictionary.cambridge.org/define.asp?key=41507&dict=CALD are what I base my objection. What we have are "request paths" as described in http://martin.gleeson.com/pwebstats/glossary.html, http://www.cs.jcu.edu.au/CIE/RFC/2068/4.htm, and http://www.griffin.uga.edu/aemn/report6/glossary.htm (see "Hit (Request)").
Comment #23
alexanderpas CreditAttribution: alexanderpas commenteduser display:
relative paths will be used for your website's internal links.
absolute paths will be used for your website's external links.
internal is the opposite of external, therefor, i still say, internal links have internal paths.
HOWEVER!!!
to make a difference beween the requested path (
news/bully) and the system path (node/30), we should document it likewise.Therefor, i suggest:
user facing (consistently):
- internal path: will be displayed to the user when talking about paths for internal links(e.g. menu system), the opposite of an external url.
documentation (detailed)
- request path: the actual requested path, for example,
news/bully, is possibly an url-alias, used for example on a page load.- internal path: used in for example the menu system, similar to request path, but not for the actual requested page, but for other pages
- system path: the actual system path, for example
node/30, never an url alias.comments are welcome.
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commented@alexanderpas: I agree except that relative paths are shown to the user as absolute paths so the difference to the end user is obscured. However, your suggestion is good and I'm marking CNW for support of that suggestion.
Comment #25
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedStill a valid issue.
Comment #38
smustgrave CreditAttribution: smustgrave at Mobomo commentedWith 12 years of inactivity wonder if this is still a valid feature request.