Use "Drupal translations website" instead of Drupal translation server or Community translation server

I'm wondering whether we shouldn't utilize drupal_install_profile_distribution_name() here for distribution-friendliness. I haven't checked recently whether that is actually the case, but in theory a distribution should be able to wipe the term "Drupal" completely from the user interface. I think the pattern that we usually use would be:

t('@Drupal translations website', array('@Drupal' => drupal_install_profile_distribution_name()));

Of course not every distribution will create its own translation server, so this might be misleading as well...

Well, e.g. OpenAtrium has its own translation server, so they would definitely want that string to read "OpenAtrium translations website" or whatever. AFAIK Drupal Commons does not have such a thing, so they might want it to read "Drupal translations website" or not, I don't know.

Just to be clear, I personally think the only consistent way to do this is to use drupal_install_profile_distribution_name(). That way we keep to our contract that we give install profile developers: "Put something in 'distribution name' and that will replace the word 'Drupal' everywhere in the UI." But, as mentioned above there might be cases where install profiles actually do want this to say "Drupal". It's not optimal, but I guess in those cases resorting to string overrides or whatever should be OK.

Updated issue summary.

Updated issue summary.

Updated issue summary.

I updated the issue summary with some info on files that need to be changing and what pages are affected.

Note: I am assuming that we don't want to change the *internal* (developer) use of the term in comments and code that is not shown to the person installing/configuring Drupal. If we need to change the use of the "translation server" term *everywhere* (including internally-consumed text) then this will be a bigger issue and might not be suitable for a novice.

Updated issue summary.

Updated issue summary.

I made a list of files that need changing. I'll make a patch.

Looking in the code for localize.drupal.org, I find that it is not even used directly so localize.drupal.org is only referenced from within the comments and documentation. The translation files are grabbed using the server_pattern setting:

    // An array of server variables that will be substituted into the global
    // $_SERVER array via drupal_override_server_variables(). Used by
    // non-interactive installations only.
    'server' => array(),
    // The server URL where the interface translation files can be downloaded.
    // Tokens in the pattern will be replaced by appropriate values for the
    // required translation file.
    'server_pattern' => 'http://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po',

It seems logical to me to add a 'server_name' to the config (defaulted to "Drupal translations website") and then use that in any t()/st() functions where the translation server is mention.

Thoughts?

#10 Adding server_name sounds like a good idea.

I'm working on a patch. Thanks!

Maybe we want to make it "the translations website" then and use the pattern set in config to link, and *that* would be general enough on the UI and flexible enough in terms of the link. However the pattern/url looks like would not lead to anything useful in itself, ha!

Yeah, the "server_pattern" goes off to ftp.drupal.org so that's not useful. What about making a "server_url" config setting and then using the generic "the translations website" text and linking to the "server_url"? As a side note, it is confusing that "server_pattern" is used for the config name... it is not obvious that it is for translations. Maybe I should open an issue?

I think we used to want to have the human facing server URL as well, but then cut it back to only the necessity items. So that is how we ended up with only the download URL and not the nicely formatted real website URL.

So, then, I shouldn't add it because it won't be accepted?

I'm waiting until:

#1861934: Rework help text for UI translations and importing po files

lands because there is some overlap in the text.

Unassigning from me in case the other issue gets resolved quickly and someone wants to do this during the sprint.

#1861934: Rework help text for UI translations and importing po files was just committed.... adding sprint tag in case someone wants to work on it :) Otherwise, I'll try to look at it again in a couple days.

Updated issue summary.

Sounds like this should not be postponed anymore. Keeping on sprint as a simple task for someone (for now) :)

Working on a patch on this today.

The files which needed to be edited are different than those stated in the issue summary due to other changes that have been made in the interim.

The two files which contained non-genericized references to the Drupal translation server, and which I edited were :
/core/modules/locale/locale.module
/core/modules/locale/lib/Drupal/locale/Form/LocaleSettingsForm.php

None of these files currently contain the "Drupal translation server" language, so I did not make any changes to them:
/core/INSTALL.txt
/core/includes/install.core.inc
/core/modules/locale/locale.install

I verified that the correct language "Drupal translation website" occurs during installation and on the following two pages:

/admin/config/regional/translate/import
/admin/config/regional/translate/settings

Noticed the word "Translation" was capitalized on install page, so lowercased it for consistency.

@manningpete: thank you! There has been some discussion above from #2 as to whether it would be better to use the distribution name in place of 'Drupal' (which we do elsewhere). Can you look into updating the patch to have that suggestion incorporated? Basically using the pattern outlined in #2. Thanks again!

This is my first patch for D8. Hope it helps :D

Thanks!!

My first interdiff, although it seems the same that the patch file. I must have done something wrong.

I didn't apply the last patch.
I created new patch.

30: change-server-to-website-1861930-30.patch queued for re-testing.

While fixing the bug, let's also get back to one of the original goals and replace "server" with "website" in the test too.

Add drupal_get_distribution_name() function in common.inc and replace "server" with "website".

Here are the screenshots of the modifications in place.

Installer screen:

Import screen:

Help screen:

Shouldn't the copy be updated during install in requirements fail case as well?

Assigning to myself to work on incorporating #39 into this as well.

Replaced "server" with "website" in all message.

41: change-server-to-website-1861930-41.patch queued for re-testing.

41: change-server-to-website-1861930-41.patch queued for re-testing.

41: change-server-to-website-1861930-41.patch queued for re-testing.

@tstoeckler: how do you like this code, especially the newly added function? :) It looks to me it is as good as it can get, given the functions it uses...

@tstoeckler asked for the profile stuff in #2/#4. The drupal_install_profile_distribution_name() code is install only (see https://api.drupal.org/api/drupal/core%21includes%21install.inc/function...), although it may work on a runtime site as well, it is placed in install.inc which is not loaded on a runtime site. So if we want to display the distro name later on, there seems to be no function for that.

Not doing the distro name change would basically ignore #2/#4. It is fine to break this up even more but its already not a big change and mostly text anyway.

I thought this would be easy to do, and its definitely not worth our time debating this and making it hard for ourselves, so removing from our sprint to keep us focused on more important things.

Instead of addressing #2143615: No "Drupal" in UI text -- config_translation, content_translation, locale, language, and translation server parts of installer later on...

Can't we simply remove the word "Drupal" from all of these instances?

That way, the completely internal detail of what exact translation server/website is used for downloading translations by an installation profile or distro is no longer an issue.

It's unnecessary repetition to begin with: You know that you are installing this product called "Drupal" or "OpenAtrium" or whatnot. It uses a translation server/website. Isn't it obvious that this (whichever) translation server/website belongs to the product?

I assume that the prefix "Drupal" only exists to clarify that the referred to translation server/website is external; i.e., it is not something that exists on your local website.

If that is the intention, then let's simply call it "external translation website"

(or "server", or "service", or perhaps ideally "repository" — not sure whether I agree that "website" is really the appropriate term)

That would be the most elegant solution IMHO.

On top, it would completely eliminate the need for distros/install profiles to replace a whole bunch of strings (+ translate into a dozen of languages), just to conditionally remove/replace the word "Drupal" — conditionally, because that depends on whether l.d.o is used or not.

Alright, attached patch implements #55. I've kept the proposed wording of "website", but consistently using "external translation website".

In addition, wording in the very first installer screen is simplified and reduced to the max:

Before:

After:

Despite the changes in this patch, the user interface is apparently still littered with the string "Drupal" all over the place. We can re-purpose #2143615: No "Drupal" in UI text -- config_translation, content_translation, locale, language, and translation server parts of installer to fix/remove all of the other instances.

Also (this has been discussed before in here), the system does not allow installation profiles to supply a custom translation website URL yet. We will need to add a new installation profile .info.yml property to support that. However, that's a separate issue.

@sun: Good stuff! I like the proposed changes. Shorter explanations meaning the same thing are useful in general anyway :) Recategorizing as user interface text to hopefully get review from the group shepherding that. Needs issue summary update to summarize the current proposal.

#2091459: Update hook_help for Locale module deals with the same Drupal translation server question, I posted there too.

Coming from the issue in #58...

So, for accessibility, the link text "downloaded" is not good link text. The link needs a title describing where it's going ("downloaded", the link text, doesn't), and then you are back to the problem of what to call the server.

So the patch in #56 is not OK.

I just installed D8 for the first time in awhile and think that it would be better UX if the "Drupal Translation website" link used target="_blank" so that it opens in a new window. I think it is confusing to open in the same window. Can we add this to this patch or does it have to be its own issue? Thanks!

Here's a re-roll of #56 with #59 and #60 included. It also updates the copy for help text implemented in #2091459: Update hook_help for Locale module to reflect the change from "Drupal translation server" to "external translation website"

Status change

Only see one technical issue in #61.

+++ b/core/lib/Drupal/Core/Installer/Form/SelectLanguageForm.php
@@ -73,8 +73,9 @@ public function buildForm(array $form, array &$form_state, $install_state = NULL
+        '#markup' => String::format('<p>Translations will be <a title="Download from external translation website" href="@translations-url" target="_blank">downloaded</a> automatically. ¶

Trailing whitespace on this line.

nonsie: Also when you make a new patch on an existing issue, please include an "interdiff" file. Thanks!
https://drupal.org/documentation/git/interdiff