Currently the Drupal core codebase is scattered with references to both "install profiles" in some places and "installation profiles" in others.
We should standardize on one single terminology, above all, for consistency in documentation.

"Installation profile" is more natural sounding language. I decided to consult what the codebase uses so see if that would sway the vote, but sadly, there is no measurable consensus or consistency there either:

* 34 instances of "install profile"
* 38 instances of "installation profile"

Most, if not all, of the references to "install profile" are in code comments, while "installation profile" is used in user-facing strings, but there are exceptions. core/includes/install.inc uses "install profile" consistently while core/includes/install.core.inc uses "installation profiles". CHANGELOG.txt uses "install profile". The two core installation profiles both use "install profile".

A Google search for "drupal install profile" turns up the top 6 results having "installation profile" in their title.

A search for both "install profile" and "installation profile" on the Drupal core issue queue shows that most issues have "install profile" in their titles, presumably for brevity.

On #1539940: Encourage best practices in /sites/README.txt, /modules/README.txt, /profiles/README.txt and /themes/README.txt, we decided to go with "installation profile", for readability. This is a follow up issue to bring the rest of the codebase into consistency.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jhodgdon’s picture

Title: [meta] Standardize on "installation profile" instead of "install profile" » [policy/patch] Standardize on "installation profile" instead of "install profile"
Issue tags: +Coding standards, +ui text

Since there are only 30-something instances that need changing, this probably doesn't need to be a meta-issue -- we can do them all in one patch. I propose that we make a patch that standardizes on "installation", and leave it at RTBC for a few days in case anyone objects.

We should also add this to
http://drupal.org/style-guide/content
once we've agreed upon a standard.

webchick’s picture

+1 to both the proposed change, and the proposed method. One patch is infinitely easier to review + commit than 30. :) For ones that are just straight-up find + replace (as opposed to changes that do need individual human review), this is a good approach.

jwilson3’s picture

Status: Active » Needs review
FileSize
18.93 KB

As stated above, the vast majority of these are in code comments.

Where it made sense in a few places I made adjustments to conform to 80-character line limit for comments.

jwilson3’s picture

Addendum, change various instances of "at/on install time" to more natural sounding "during installation".

jhodgdon’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs backport to D7

I noticed:
#1802280: Incorrect documentation in drupal_system_listing()
But that is a separate issue.

I think this patch is good (thanks!), so I'm provisionally marking it RTBC to see if anyone objects to the idea of standardizing on "installation profile" -- let's wait a couple of days before committing it.

I also think everything except the translated string change (I think there's only one) can be ported to Drupal 7 as well (and should be).

webchick’s picture

Assigned: Unassigned » jhodgdon
Category: feature » task

Sounds fine to me, fwiw. Feels more like a task and not something that should be subjected to thresholds, so re-categorizing.

Jennifer can drive this home, so assigning to her so I don't factor it into my RTBC queue count. :)

Dries’s picture

Fine with me too.

jhodgdon’s picture

Version: 8.x-dev » 7.x-dev
Assigned: jhodgdon » Unassigned
Status: Reviewed & tested by the community » Patch (to be ported)

Well, this has been RTBC with proper tags for a few days. No one has objected and two heavy-hitters have agreed, so I went ahead and committed this. Time to backport to 7!

I also edited
http://drupal.org/style-guide/content#relatedwords
to add this textual standard.

jwilson3’s picture

Status: Patch (to be ported) » Needs review
FileSize
25.32 KB

Backported.

jwilson3’s picture

+++ b/includes/update.incundefined
@@ -785,11 +785,11 @@ function update_fix_d7_requirements() {
- * Install profiles are now treated as modules by Drupal, and have an upgrade
+ * Installation profiles are now treated as modules by Drupal, and have an upgrade
  * path based on their schema version in the system table.
  *
- * The install profile will be set to schema_version 0, as it has already been
- * installed. Any other hook_update_N functions provided by the install profile
+ * The installation profile will be set to schema_version 0, as it has already been
+ * installed. Any other hook_update_N functions provided by the installation profile
  * will be run by update.php.

These lines were hanging over 80 columns.

jhodgdon’s picture

Status: Needs review » Needs work

Thanks, this looks great!

The only thing is, we don't want to make changes to translated strings in D7, so we need to remove these changes:

-      'display_name' => count($install_state['profiles']) == 1 ? st('Install site') : st('Install profile'),
+      'display_name' => count($install_state['profiles']) == 1 ? st('Install site') : st('Installation profile'),

-    $this->assertIdentical(drupal_get_filename('profile', 'standard'), 'profiles/standard/standard.profile', t('Retrieve install profile location.'));
+    $this->assertIdentical(drupal_get_filename('profile', 'standard'), 'profiles/standard/standard.profile', t('Retrieve installation profile location.'));

-        'title' => $t('Install profile'),
+        'title' => $t('Installation profile'),
jwilson3’s picture

jwilson3’s picture

Status: Needs work » Needs review
jwilson3’s picture

jwilson3’s picture

OMG, I must be tired... I miss-named the patch.

This is the same as in #14, but with a -D7 tag on the end.

jhodgdon’s picture

Assigned: Unassigned » jhodgdon
Status: Needs review » Reviewed & tested by the community

Regarding patch names, don't worry about that! If the issue is D7, then we'll know the patch is for D7. :)

Anyway, this looks good, and I'll get it committed shortly. Thanks!

jhodgdon’s picture

Status: Reviewed & tested by the community » Fixed

Committed... thanks again for your work on this jwilson3!

jhodgdon’s picture

Assigned: jhodgdon » Unassigned
jwilson3’s picture

Excellent!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

David_Rothstein’s picture

Version: 7.x-dev » 8.x-dev
Status: Closed (fixed) » Needs review
FileSize
640 bytes
-      'display_name' => count($install_state['profiles']) == 1 ? st('Install site') : st('Install profile'),
+      'display_name' => count($install_state['profiles']) == 1 ? st('Install site') : st('Installation profile'),

This one is wrong for Drupal 8 also, since "install" was being used as a verb here. (I.e., compare to "Choose profile" which is one of the earlier installation tasks.)

I just installed a new copy of Drupal 8 and got really thrown off by the new wording.

Here's a patch which fixes that.

webchick’s picture

Hm. Would it be more correct then to call this step "Choose installation profile"? You're not actually installing anything here.

I'm not sure how that jibes with the rest of the task labels in terms of length, though.

David_Rothstein’s picture

FileSize
30.47 KB

The step where you choose an installation profile is already called "Choose profile". This is the step where the modules are being enabled.

Attached screenshot may help.

I suppose it would be possible to rename them both ("Choose installation profile" and "Enable installation profile"), but that would get long and would probably spill over into more than one line. As can be seen in the screenshot, they're already spilling to multiple lines as it is, but that's some kind of D8 theming bug (because the entire task list is squished horizontally) - in D7 they all are on one line, at least for me.

jwilson3’s picture

Thanks David for bringing this up. I dont have a strong opinion about this, so using your patch in #21 I think would be the most straightforward solution, but I thought it might be worth exploring two other possibilities while were looking at this. For the record, I don't like "Choose installation profile" and "Enable installation profile" as they really are too lengthy, but I would point out as devil's advocate that the "Verify requirements" step already breaks to two lines (on my screen anyway) so that alone shouldn't be the basis of rejecting that idea.

Two thoughts:

a) Is it even necessary to distinguish between "installing a site" and "installing a profile"? If not, we could just say "Install site" for all cases.

b) The user isn't actually doing anything on this step to justify there being an action verb in the title, so maybe just "Installation" might make sense here too.

To put these into context here's what it might look like:

a)
* Choose language
* Choose profile
* Verify requirements
* Set up database
* Install site
* Configure site
* Finished

b)
* Choose language
* Choose profile
* Verify requirements
* Set up database
* Installation
* Configure site
* Finished

jhodgdon’s picture

David: Thanks for catching that mix-up!
RE #24 - I think "Install site" makes more sense -- option (a). Option (b) to me is a bit jarring because everything but "Installation" is a verb... and really the whole process is "installation"... Some of the other steps don't make a whole lot of sense either, given what they actually do. And there are also some other steps that aren't shown in this list, under certain circumstances. The whole list (for people installing in non-English languages) is currently:

Choose language [user chooses a language]
Choose profile [user chooses a profile to use]
Verify requirements [system checks requirements]
Set up database [user enters database information, system verifies it can connect]
Install site/Install profile [modules/themes are installed]
Set up translations [system sets up languages and imports translations it knows about]
Configure site [user enters site information, system saves it]
(tasks added by your profile)
Finish translations [import remaining translations if any]
Finished

So... I'm not really thrilled by "Install site", since to me the whole process is "installing a site", right? Also not thrilled with "Set up database", since the database tables are not set up until the next step really. And one of the "set up" steps means "you enter information", while the other is "the system sets stuff up"... So how about if we change this to:

Choose language
Choose profile [should this be "Choose installation profile"? or is that too long? did we discuss above?]
Verify requirements
Configure database
Install database
Install translations
Configure site
(tasks added by your profile)
Finalize translations
Finished

This way, the things you have to do are "Choose" and "Configure", and the things the system does are "Verify" and "install" and "finalize".

Thoughts? Is this out of scope for the issue?

jwilson3’s picture

Status: Needs review » Needs work

"some of the other steps don't make a whole lot of sense either"

Completely agree.

is this out of scope for the issue?

Maybe it could be a bit of scope creep, but I think this is completely related to standardizing on "installation" versus "install", so I'd rather see it fixed correctly here on this issue, since the history from #21 outlines why this caused confusion and was easily missed in the first place when I did the search/replace. Perhaps thats the wrong reasons to not move it to a new issue tho, not sure.

Anyway, I like #25 a lot, so I'll mark needs work for now, and see what David and Angie say.

ifrik’s picture

Should this still be taken up before we get to RC1, so that translators can work on consistent wording?

If so, it should be tagged with Barcelona2015.

dawehner’s picture

It is certainly always better to change strings rather earlier than later.

Here is a crazy idea: Core could come with a better_help module which requires locale and translates the existing help in a way that it contains things properly. Just an idea though.

ifrik’s picture

Issue tags: +Barcelona2015
webchick’s picture

It seems like if we were going to standardize on anything, we'd standardize on "Distribution." That's what Drupal.org calls these things.

jhodgdon’s picture

When you download a distribution, it's called a distribution.

However, when you go to the installation screen, it tells you to choose your installation profile, not your distribution, and for that matter when you download just regular Drupal, you have a few profiles to choose from (distros may also?).

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • jhodgdon committed 8aa4fdb on 8.3.x
    Issue #1799116 by jwilson3: Standardize on installation profile term vs...

  • jhodgdon committed 8aa4fdb on 8.3.x
    Issue #1799116 by jwilson3: Standardize on installation profile term vs...

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ifrik’s picture

Should we tag this for the sprints at Drupalcon Dublin?

  • jhodgdon committed 8aa4fdb on 8.4.x
    Issue #1799116 by jwilson3: Standardize on installation profile term vs...

  • jhodgdon committed 8aa4fdb on 8.4.x
    Issue #1799116 by jwilson3: Standardize on installation profile term vs...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

  • jhodgdon committed 8aa4fdb on 9.1.x
    Issue #1799116 by jwilson3: Standardize on installation profile term vs...

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
quietone’s picture

Version: 9.3.x-dev » 8.0.x-dev
Status: Needs work » Fixed
Issue tags: -Needs backport to D7

This patch was committed to Drupal 8 and Drupal 7 and then re-opened because 'installation profile' was appearing as a step on the installation screen on Drupal 8. That text was changed in #1351352: Distribution installation profiles are no longer able to override the early installer screens to 'install site' and there is nothing more to do here.

Therefor changing to fixed and setting the version bask to Drupal 8.0.x

Thanks all!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.