Problem/Motivation
There are a couple of URLs pointing to either wikpedia or php.net in hook_help() and other user interface strings, as well as in API documentation.
The links in UI strings should be localizable, and the links in API documentation and UI strings should be unlocalized.
Proposed resolution
a) In API documentation and other code comments, we should put in unlocalized links to php.net and wikipedia.org, rather than ones with "us" or "en" in them. Examples:
http://php.net/manual/function.date.php (unlocalized -- good)
vs.
http://us1.php.net/manual/en/function.date.php (localized -- bad)
https://wikipedia.org/wiki/Elie_Wiesel (unlocalized -- good)
vs.
https://en.wikipedia.org/wiki/Elie_Wiesel (localized -- bad)
b) In user interface text strings (anything inside t(), including hook_help() implementations) we should include the php.net and wikipedia.org links in the translated string, so that translators can change the link URL to a localized link if desired. So we should do this:
t('See <a href="http://wikipedia.org/wiki/whatever">the Wikipedia page on whatever</a> for more information');
rather than pulling the URL out like we have been doing:
t('See <a href="!wikipedia">the Wikipedia page on whatever</a> for more information', array('!wikipedia' => 'http://wikipedia.org/wiki/whatever');
And the URL we put in there should be unlocalized.
However, note that changes to UI strings are discouraged at some stages of the product release. So making a change to a UI string that pulls the URL inside so it can be localized is good, because it fixes the bug that they cannot currently be localized. But just changing the link so it doesn't contain a 'en' or 'us' is not enough of a bug to justify the UI string change.
Remaining tasks
Find all the links and strings that need updating, and make a patch.
User interface changes
Links to php.net and wikipedia.org will be localizable.
Translatable UI strings are affected.
API changes
No.
Data model changes
No.
Comment | File | Size | Author |
---|---|---|---|
#62 | interdiff-2571845-60-62.txt | 3.33 KB | anil280988 |
#62 | core-localized-links-2571845-62.patch | 57.02 KB | anil280988 |
#60 | core-localized-links-2571845-60.patch | 54.35 KB | hussainweb |
#28 | interdiff-27-24.txt | 3.15 KB | drupal.ninja03 |
#28 | core-localized-links-2571845-28-D8.patch | 109.67 KB | drupal.ninja03 |
Comments
Comment #2
dawehnerComment #3
jhodgdonMy opinion is that the URLs should be within the t() text so they can be changed to more appropriate localized links.
Comment #4
stefan.r CreditAttribution: stefan.r commentedAgreed with #3
So in the cases where we do this:
Should we do:
The advantage of b) is we only need to translate a URL once, the advantage of a) is we have more context.
Comment #5
jhodgdonAh, good question. The other advantage of (b) is that it only adds a string to the translation set, and doesn't change the existing strings.
So. Regarding php.net, we already have a solution to that, which is that PHP.net URLs are *supposed* to not have the "en" in them, because if you visit a URL like
http://php.net/manual/function.date.php
it should redirect you to an appropriate, localized page, like
http://us1.php.net/manual/en/function.date.php
in my case.
If we have php.net URLs with 'en' or 'us' in them, that is wrong and we should fix it, and I think we don't need to put the URLs in t().
Maybe Wikipedia does the same? Can someone whose browser language and country is other than EN/US try to visit this URL and see if it redirects you to your own language? Let's see...
https://wikipedia.org/wiki/Elie_Wiesel (his birthday is today)
That redirects me to
https://en.wikipedia.org/wiki/Elie_Wiesel
So... If we can do the same with Wikipedia as we can with php.net, then I think we can just fix the URLs instead of actually needing to translate them.
Then if we have a few links that point to sites other than php.net or Wikipedia, we can t() them.
Can someone tests the redirects to languages other than English in the above URLs, to see if this is viable?
Comment #6
stefan.r CreditAttribution: stefan.r commentedMy browser has a preferred language of French but both http://php.net/manual/function.date.php and https://wikipedia.org/wiki/Elie_Wiesel go to English pages
Comment #7
jhodgdonHm. I wonder if it is based on location/IP address...
Comment #8
snehi CreditAttribution: snehi as a volunteer and at Publicis Sapient for Publicis Sapient commentedChanged instances from
to only
in all the files.
Unable to find any link like
Found one with
and i replaced it with
Comment #9
jhodgdonHm. According to comment #6, those no-language Wikipedia and php.net links do not redirect people to the localized pages, unless there is something weird going on for stefan.r. No one else has tested the links in #5 to wikipedia and php.net to see if they redirect. If they don't redirect for anyone, we need to do something else in this patch than this.
So if we could have a few other people who:
a) Are located in a non-English-speaking country
b) Have their browser's default language set to a non-English language
test the non-localized php.net and wikipedia.org links in #5 and report here where they redirected to, that would be great! Then we can figure out what to do in this patch.
Comment #10
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedHi,
I second comment#6. I have tested according to comment#5 & #9 and set my browser language to Hindi and Assamese but I am getting same result as comment#6.
Comment #11
jhodgdonOK then. Thanks for testing!
In that case, it looks like the strategy of trying to put unlocalized links in is not going to work. So, here is what I think we should do [adding this to the issue summary too]:
a) In API documentation and other code comments, we should put in unlocalized links to php.net and wikipedia.org, rather than ones with "us" or "en" in them. Examples:
http://php.net/manual/function.date.php (unlocalized)
vs.
http://us1.php.net/manual/en/function.date.php (localized)
https://wikipedia.org/wiki/Elie_Wiesel (unlocalized)
vs.
https://en.wikipedia.org/wiki/Elie_Wiesel (localized)
b) In user interface text strings (anything inside t(), including hook_help() implementations) we should include the php.net and wikipedia.org links in the translated string, so that translators can change the link URL to a localized link if desired. So we should do this:
rather than pulling the URL out like we have been doing:
And the URL we put in there should be unlocalized.
Comment #12
jhodgdonAdding a note about translatable strings to the issue summary.
Comment #13
GoZ CreditAttribution: GoZ at Centarro commentedYou can find some other urls to fix in https://www.drupal.org/node/2591919#comment-10455511
Comment #14
drupal.ninja03 CreditAttribution: drupal.ninja03 as a volunteer and at Publicis Sapient for Publicis Sapient commentedAs mentioned in #11, i have just created the patch for it. This is my first patch in Drupal, i might be wrong here.
Please review attached one.
Comment #15
GoZ CreditAttribution: GoZ at Centarro commented@passionate.drupalist can you add an interdiff file ? https://www.drupal.org/documentation/git/interdiff
There is still some urls to fix. See link from #13
Comment #16
jhodgdonThanks!
Please read the issue summary about what we do and do not want to change in this patch, and see below for some things that need to be fixed in this patch.
We should remove the extra "SOAP" at the end of this line.
This URL still has 'en' in it.
Still contains 'en'.
As discussed in an earlier comment, right now we do *not* want to change localized URLs to localized URLs within UI strings (i.e., inside t() calls).
If the URL is not part of the t() string at all, it's a bug that we would want to fix. But if the URL is already there (as in this case), we don't want to change it because this would change the string for translators and it's not so major of a bug.
See previous comment.
see previous comment
See previous comment
Now in this case, that is what we *do* want to change. The wikipedia string is not currently part of the translated piece of the string. So we would want to move it in there so it can be translated/localized.
Same here.
Don't make this change (see above).
Comment #17
drupal.ninja03 CreditAttribution: drupal.ninja03 as a volunteer and at Publicis Sapient for Publicis Sapient commentedHi,
As mentioned in #16, changes has been done. Please review.
Comment #18
jhodgdonThanks! Better, but still a few things to fix. Again, please read the issue summary.
This URL still has 'en' in it.
Again, we want to put the URL ***into the main t() string*** here. Read the issue summary please. There are a few other places in the patch where this also needs to be done.
Comment #19
GoZ CreditAttribution: GoZ at Centarro commentedClosed issue linked in #13 should also be considered.
Please, add those changes removing all
/en
from php.net urls.Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url, remove
@url
param fromt()
and put it in translatable string like suggested in b/ from the issue summary.Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url, remove
:opcache_link
param fromt()
and put it in translatable string like suggested in b/ from the issue summary.Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Remove /en from php.net url like this patch does.
Comment #20
drupal.ninja03 CreditAttribution: drupal.ninja03 as a volunteer and at Publicis Sapient for Publicis Sapient commentedHi,
Please pardon my mistakes earlier. I have now made the remaining changes that got left out earlier as pointed out in #18 and #19. Please review it.
Comment #21
GoZ CreditAttribution: GoZ at Centarro commentedI think we are pretty closed. Thanks for your stuff.
Still a few things.
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Remove www. from www.php.net
Comment #22
GoZ CreditAttribution: GoZ at Centarro commentedRemove /en from www.php.net/manual/en/
You miss /en in php.net/manual/en
Comment #23
drupal.ninja03 CreditAttribution: drupal.ninja03 as a volunteer and at Publicis Sapient for Publicis Sapient commentedHi,
I have made the changes mentioned in #21 & #22. Please review it.
Comment #24
GoZ CreditAttribution: GoZ at Centarro commentedDamn fast. Still few thinks in this diff
Still have php.net/manual/en
Replace placeholders directly by urls.
Replace placeholder by url.
Comment #25
GoZ CreditAttribution: GoZ at Centarro commentedI found some not noticed yet place where php.net are displayed in t() with placeholders :
'#description' => $this->t('See <a href=":url" target="_blank">the documentation for PHP date formats</a>.', [':url' => 'http://php.net/manual/function.date.php']),
line 105
line 112
line 31
line 52
line 20
line 249
line 107
line 381
Comment #26
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedHi,
As per comment#24 and #25, I have made the necessary changes and corrections. I hope this is exactly what you need. Kindly review my patch. Thanks.
Comment #27
GoZ CreditAttribution: GoZ at Centarro commented:uploadprogress_url should be replaced by url in t()
:syslog should be replaced by url in t()
When you make a patch, you should name it with comment number you'll post it, and not comment your patch try to fix. You can use "Patch name suggestion" Button in right of upload area to help you naming your patch. So interdiff also refer to 2 comments where patchs are posted.
Comment #28
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedHi GoZ,
I have made the changes suggested by you and uploaded the patch and interdiff files. Please review it. Thanks.
Comment #29
GoZ CreditAttribution: GoZ at Centarro commentedSeems good to me and ready to RTBC.
Someone see something else missing ?
Comment #31
stefan.r CreditAttribution: stefan.r commentedThis can be removed.
Other than that I think the current approach is fine, the difference with HEAD is that we stop using the
t('<a href=":url">')
pattern for "translatable" URLs and instead put the URL in the translatable text directly.Comment #32
stefan.r CreditAttribution: stefan.r commentedComment #34
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedHi stefan.r,
I believe you are looking at an old version of the patch file I have submitted. Please review the latest file: core-localized-links-2571845-28-D8.patch as mentioned in comment#28.
Thanks.
Comment #36
stefan.r CreditAttribution: stefan.r commentedhttps://www.drupal.org/files/issues/core-localized-links-2571845-28-D8.p... still has that piece of code...
Comment #37
stefan.r CreditAttribution: stefan.r commentedhttps://www.drupal.org/files/issues/core-localized-links-2571845-28-D8.p... still has that piece of code...
Comment #38
stefan.r CreditAttribution: stefan.r commentedhttps://www.drupal.org/files/issues/core-localized-links-2571845-28-D8.p... still has that piece of code...
Comment #39
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedHi Stefan.r,
I have removed the lines you have highlighted. Please review it. Thanks.
Comment #40
GoZ CreditAttribution: GoZ at Centarro commented@drupal.ninja03 you miss interdiff
Comment #41
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedHi GoZ,
Interdiff attached. Please review.
Comment #42
GoZ CreditAttribution: GoZ at Centarro commentedOk, my bad. I make you add some changes in vendor/ files. I should be tired this day... Vendors should not be changed.
Please remove them and forgive me for this bad request.
There is something wrong with your interdiff, please read https://www.drupal.org/documentation/git/interdiff to know how to generate interdiff.
Comment #43
anil280988 CreditAttribution: anil280988 at Publicis Sapient for Publicis Sapient commentedHi GoZ/drupal.ninja03,
Remove the changes listed in comment #42, @GoZ.
Comment #44
jhodgdonThanks for the patches! Sorry for delay in reviewing, I've been on vacation...
This is mostly good. A few notes:
This is over 80 characters and should be wrapped.
This @link is wrong. There is no @endlink. Presumably it should be a @see instead? And should be at the end of the doc block.
IMO, we should drop this change. The wikipedia URL is already part of the string, and I don't think it's worth invalidating translations to remove the "en" from the URL.
Same here.
Same here.
Now here, we are moving the URL into the string, and that is important to do, so we do want this change.
Another one we shouldn't change.
I don't understand why we are escaping the name of the strtotime function here. Let's move this into the main string too instead of using @strtotime?
:uploadprogress_url should also be moved into the string.
:exif URL should be moved into the translatable string.
:url should be in the string.
Should not make this string change.
We generally do not move drupal.org URLs into the translatable strings.
Probably should not make this change.
In // comments, we usually do not use @see. Just say "see".
Lost the h in http. Also this should be @see, and we need to lose the en. in the URL.
Should be @see and at the end of the doc block. Also need to lose the /en in the URL. And why did you add www?
Comment #45
Himanshu5050 CreditAttribution: Himanshu5050 at Publicis Sapient for Publicis Sapient commentedComment #46
Himanshu5050 CreditAttribution: Himanshu5050 at Publicis Sapient for Publicis Sapient commentedComment #47
r_sharma08 CreditAttribution: r_sharma08 at Publicis Sapient for Publicis Sapient commentedApplied patch.
#13 did not patched, as I need more clarity. how to resolve it?
Please review.
Comment #49
hussainwebFixing for comments in #44. I removed the changes pointed in 16 and 17 as that was in vendor and we shouldn't touch that here at all.
Comment #50
hussainwebI think I lost the interdiff in crosspost. Here it is.
@r_sharma08: There was a PHP error in your patch as we can see from CI output. Can you review the patch I uploaded instead? It also fixes for the point 13. Please let me know if you need any help.
Comment #51
r_sharma08 CreditAttribution: r_sharma08 commentedThanks hussainweb.
Comment #52
r_sharma08 CreditAttribution: r_sharma08 commentedThanks hussainweb.
Comment #53
jhodgdonOK... Within the scope of this issue, the patch is OK. As it is changing translatable strings, I am changing the component to "other". I suspect that it may be pushed off to 8.1.x but I am not sure about the policy on translatable strings so we'll see.
Updated the issue summary to highlight that translatable strings are affected.
Comment #55
anil280988 CreditAttribution: anil280988 at Publicis Sapient for Publicis Sapient commentedHi,
How this patch has gone to Needs Work again? Do we have to upload the last patch again?
Comment #56
jhodgdonRE #55, if you click through to the failed test in #49, it looks like the patch does not apply.
Comment #57
hussainwebRerolling due to clashes in #2617568: Rename apc_* functions with apcu_*.
Comment #58
jhodgdonThanks! Looks like a few new items were added; they're all fine. Back to RTBC. Moving to 8.1 because I think UI text changes that are non-critical (like these) are being moved there. After commit to 8.1, we should consider porting the non-UI part back to 8.0.x too. Thanks!
Comment #60
hussainwebRerolled. Back to RTBC because the change in this patch for run-tests.sh was done in #2605290: Improve docs, coding standards for run-tests.sh and hence the conflict.
Comment #61
alexpottThis looks like we should be putting it inside the strings below so that translators can localise - according to the issue summary.
Comment #62
anil280988 CreditAttribution: anil280988 at Publicis Sapient for Publicis Sapient commentedHi alexpott/hussainweb,
Made the changes. Kindly suggest if anything else needed to be fix.
Comment #63
hussainwebThanks @anil280988. Changes look good. RTBC +1.
Comment #64
anil280988 CreditAttribution: anil280988 at Publicis Sapient for Publicis Sapient commentedAll the changes looks good now. Change suggest by alexpott is also implemented. Putting it to RTBC so that it could be closed, if its correct, as it is hanging for long time. Give suggestion if more changes are required.
Comment #65
alexpottCommitted 9067206 and pushed to 8.1.x. Thanks!
Comment #67
Balu ErtlTo the attention of translator fellows: to help your work I collected the most string changes between 8.0.0 and 8.1.x-beta1 related to this issue. Please find them at the bottom of this spreadsheet: http://goo.gl/Qjxumq. (Don't forget to select your lang code in the top cell to make the links pointing to your locale on l.d.o!)
This collection is probably not full, if you may find any others, please submit them on this form: http://goo.gl/forms/8R4Hovq2YA
Comment #68
xjm8.0.6 is the final bugfix release for 8.0.x and is released now, so this no longer needs to be backported.
Comment #70
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedThere are a couple other cases that still don't follow the recommendations that were developed in this issue - see the link for a patch.