[#19857] - Alias string consistency
- Closed
- 10 Mar 2018
- Medium
- Build: staging
- # 19857
- Diff
- brianteeman:alias
User tests: Successful: Unsuccessful:
Pull Request for Issue #19856 reported by @MartijnMaandag
Summary of Changes
On the Tab 'Publishing' we do have the label 'Created by Alias' in Contacts, Banners and Articles (although in Contacts it is 'Created By Alias' with capital 'B').
This PR makes them all "Created by Alias"
In Tags, Newsfeeds and frontend content editing this is uses a generic string called 'Author's Alias'.
This PR makes the generic string "Created by Alias" and updates the generic description
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings |
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19857.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19857.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19857.
II suggest to get rid of the "COM_CONTACT_FIELD_CREATED_BY_ALIAS_LABEL" and use in the xml the JGLOBAL_FIELD_CREATED_BY_ALIAS_LABEL string instead.
In that xml we already use some JGLOBAL strings.
| Status | Ready to Commit | ⇒ | Pending |
I am taking of the milestone and RTC until someone explains to me why the simplification I suggested above makes no sense.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19857.
Its really simple. The rules for J3 language files are that we should not delete any string. So even if we are not using the component specific string here it will still exist. Therefore there is no point in changing from the component specific string to the generic string.
It's really simple: even if the string shall not be deleted (just leave it in this case without modification although I am pretty sure it is not used by any third party) it makes sense to change in core the xml to the global one and mark the Contact one as deprecated.
we cant be certain. these are your rules not mine. I wont comment any further as you have an agenda that is nothing to do with this PR
I don't know what are the rules we have to apply here, but using a global TAG make sense.
I have understand (understanding the fact) that we are not removing TAGS from ini files, so I can see a situation coming that someone changes a component ini file and wondering why the frontend string doesn't change. So at least we need a comment within the ini file to mark a Tag as not longer in use.
I would appreciate a clear written down set of rules for handeling language files.
If we want to have a global tag for this component then we should have it for all of them.
When there is a global constant available, — and we are absolutely sure its value can't be translated differently depending on the place where it is used by any language —, it is indeed a very good idea to deprecate the local instance with the same value. As usual, and as decided previously, the deprecation should be done in next major release, i.e. 4.0.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-03-10 08:06:50 |
| Closed_By | ⇒ | brianteeman |
@brianteeman can you make this PR again for 5.1, we discussed it today and accept the solution you have proposed. Thanks in advance.
I have tested this item✅ successfully on 7b0ac02
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19857.