The help text in admin/config/regional/language/configure needs significant improvement.

Element Old Proposed
Title Languages Language detection and selection
Content Language Content language selection
Content language help If a piece of content is available in multiple languages, the one matching the content language will be used. If a piece of content is available in the detected language, the version matching the detected content language will be used.
Interface Language Interface language selection
Interface language help The interface labels will be displayed in the interface language. If an interface translation matches the detected language, it will be displayed.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jhodgdon’s picture

Maybe Content language -> Content language detection, since the word "detection" is used elsewhere on the page? Or else change the other detection strings to selection too?

Other than that, these look like good changes to me. That page is quite confusing.

john_jacobs’s picture

I agree, good improvements.

Also for consistency how about ending the Content language help section with "...it will be displayed." rather than "...it will be used." so it is consistent with the Interface language help section?

:~john

jhodgdon’s picture

Good ideas. Sounds like there's enough interest/agreement for a patch?

rfay’s picture

Assigned: Unassigned » rfay

I'll try to roll a patch later today.

rfay’s picture

Status: Active » Needs review
FileSize
3.95 KB

Here's a shot at the patch.

jhodgdon’s picture

Status: Needs review » Needs work

There are some issues with this.

a) It's not the "administrative interface". It's all Drupal-provided text. Some of it is not actually admin-related.
b) Some punctuation/style issues... consistency, clarity, etc...
c) Languages being enabled/disabled is not done on the admin/config/regional/language/configure page, so that should not be mentioned in the help text for that page.
d) I don't think that changing the settings on admin/config/regional/language/configure breaks incoming URLs. It might change how pages are displayed (that's the idea), but it shouldn't break URLs. It's the settings on admin/config/regional/language/edit/(LANG) that break URLs (which is already mentioned on the relevant fields there).
e) We're trying to avoid the word "Node" in the user interface.

New patch coming shortly...

rfay’s picture

On d): This is a forever issue, and it has to do with when path is used to disambiguate languages. It's awful. Probably should never have been done. But if you ever use the path option and turn URLs into en/something or es/something, then turn that off (or vice versa) you end up with unresolvable, completely broken links forever. This has been since 5.0 or earlier. It should probably have never been done because of the consequences.

jhodgdon’s picture

Assigned: rfay » Unassigned
Status: Needs work » Needs review
FileSize
13.13 KB

Here's a new patch, with lots of updates... Definitely needs a review!

I was going to attach screen shots, but this patch changes quite a few screens...

rfay’s picture

I think this is great - thanks for the work on this.

I changed a grand total of one word.

Screenshots are posted here for other reviewers.

My one concern (and I don't know if others agree with me): I would put in here Don't use path prefixes unless you have to. Thery're a terrible idea and will make you sorry forever. If you don't have control of subdomains, or if you have a legacy site, sure. But otherwise, use another technique.

Can we or should we put a sanitized version of that in there?

My patch changes only one word (define -> determine) as shown in the attached txt file.

jhodgdon’s picture

Status: Needs review » Reviewed & tested by the community

rfay: I don't know why you feel so strongly about path prefixes rather than subdomains? Let's leave this out.

Anyway. I prefer rfay's one-word change to my original patch, and we are both happy with the changes, so let's get this in, as it's a big improvement to describing what's going on on this otherwise very confusing set of pages.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

I glanced through these all and they look like very reasonable improvements.

Committed to HEAD!

Status: Fixed » Closed (fixed)

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

marcvangend’s picture

Status: Closed (fixed) » Needs work

I just came across this block of text, introduced by this issue, while translating D7:

URL <strong>including protocol</strong> to use for this language, if your <em>Detection and selection</em> settings use URL domains. For the default language, this value may be left blank. <strong>Modifying this value may break existing URLs. Use with caution in a production environment.</strong> Example: Specifying "http://example.de" or "http://de.example.com" as language domains for German results in URLs like "http://example.de/contact" and "http://de.example.com/contact", respectively.

In the first sentence, I'm wondering what "URL domains" means. It sounds like a pleonasm to me. I realize that we're way past UI freeze, but didn't you mean "language domains" like in the last sentence?

Feel free to close this issue again if I'm the only one who doesn't get it.

jhodgdon’s picture

Hmmm.

I think what it is trying to say is that this is the URL if your setup says to use URLs to determine the language, which you would set up on this screen:
http://drupal.org/files/issues/regional.language.configure.1.png
http://drupal.org/files/issues/regional.language.configure.2.png

and this screen:
http://drupal.org/files/issues/regional.language.configure.url_.png

So you have to be set up to use URLs for detection, and domains within the URL settings. That's what needs to be conveyed.

marcvangend’s picture

Thanks for explaining. I now understand that "URL domains" is not a pleonasm, because it differs from the "URL path prefix" method.
I think the text could have been a little clearer, but then again, I'm not a native English speaker so maybe it's just me.

jhodgdon’s picture

Status: Needs work » Fixed

I think at this point that we should just mark this issue back to fixed then. We will only make UI text changes at this point if something is actually broken...

marcvangend’s picture

Fine by me. Thanks again.

Status: Fixed » Closed (fixed)
Issue tags: -ui-text

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