Similarly to #2551453: Follow-up: Consistently use "email" instead of "e-mail" in Drupal and #950534: [policy] Consistently use "email" instead of "e-mail" in Drupal and (the much less trivial: #2560783: Replace !placeholder with :placeholder for URLs in hook_help() implementations and #2566503: [meta] Replace remaining !placeholder for Non-URL HTML outputs only), I have noticed some inconsistencies and grammar mistakes with respect to the use of the acronym, "URL" and the correct article use, e.g. "... an URL alias" should be "... a URL alias".
Also, 'URL' is an acronym, so should consistently be spelled 'URL', not 'url' or 'Url' in text visible in the UI. Ideally, we should also fix this in comments, etc, but good care should be taken to avoid accidentally hitting anything code-affecting (annotations, array keys, etc)
Motivation
Grammar mistakes and spelling inconsistencies in the UI of a software product may not inspire confidence in the product's stability in areas that are more important.
Concerns
I do have serious concerns; I was hesitant to even bother to create a ticket for this for multiple reasons, especially:
- Translation issues: Strings already translated will be orphaned and seen as 'untranslated' in every language that already has the original string translated. Fixing the .po files could be far more tedious than searching out all the places where this "fix" might be "needed"
- Testing issues: Selenium/Webdriver tests may operate in a non-English installation where checkboxes, etc, may be selected by a label (makes tests much more readable) or tests may wait for a confirmation message. But when the label/message changes (back to English, due to lost translations), tests fail. Such tests may just be in various projects, not in core, so updating trivial strings should ideally include fixing .po files at the same time.
- Trivial changes like this tend to cause conflicts when merging other, more important, changes.
- We have plenty of bigger fish to fry.
- Where do we stop?
All that said...
This fits into a larger discussion about how to track trivial string changes to maintain translations in a more automated way. So while I'm hesitant to even suggest we fix this, I want to have this issue available for discussion and (perhaps) as a place to test tracking string changes of this sort. Here, such work as that started by justAChris in #2572771: List translation string changes following replacement of !placeholder and @placeholder and discuss ways to assist translation teams may be helpful. So this issue is meant as an example. String freeze comes with the RC, and a date for that has already been announced, so if we want to fix things like this first, it must happen soon.