Conversation
… term used in Joomla! Natively.
|
I have tested this item ✅ successfully on 37cd2f3 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17409. |
| COM_MODULES_OPTION_SELECT_CLIENT="- Select Type -" | ||
| COM_MODULES_OPTION_SELECT_MODULE="- Select Type -" | ||
| COM_MODULES_OPTION_SELECT_PAGE="- Select Page -" | ||
| COM_MODULES_OPTION_SELECT_MENU_ITEM="- Select Menu Item -" |
There was a problem hiding this comment.
Are you a real person or just a super computer?
| COM_TEMPLATES_NEW_FILE_TYPE="File Type" | ||
| COM_TEMPLATES_NO_TEMPLATE_SELECTED="No template selected." | ||
| COM_TEMPLATES_OPTION_SELECT_PAGE="- Select Page -" | ||
| COM_TEMPLATES_OPTION_SELECT_MENU_ITEM="- Select Menu Item -" |
|
I have tested this item ✅ successfully on 7c342b9 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17409. |
1 similar comment
|
I have tested this item ✅ successfully on 7c342b9 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17409. |
|
RTC after two successful tests. |
|
Not RTC. We have that crazy policy about not renaming language keys because they might be used elsewhere and blah blah blah, so the old strings have to be deprecated and kept until 4.0. |
|
set back on "Pending"as stated above. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17409. |
|
Agree with @mbabker although we don't usually bother to mark language strings as deprecated |
|
Well, unless we want to keep translating strings that stopped being used in core 5 users ago because nobody ever bothers to clean that stuff out, we gotta start doing things "right" at some point. |
|
How do you even do language string depreciations?
I can add them back in no problem! Just didn't think anyone would be using them.
…On 4 Aug 2017, 18:52 +0100, Brian Teeman ***@***.***>, wrote:
Agree with @mbabker although we don't usually bother to mark language strings as deprecated
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@mbabker what is the correct method to mark deprecated? Add to end of file with a deprecated 4.0 comment?
…On 4 Aug 2017, 19:00 +0100, Michael Babker ***@***.***>, wrote:
Well, unless we want to keep translating strings that stopped being used in core 5 users ago because nobody ever bothers to clean that stuff out, we gotta start doing things "right" at some point.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
In the past, we added a comment before the deprecated string with that deprecation message. That comment will show up in com_localise (but not in Crowdin). Don't put the lines at the end of the file, keep them in the place they are. |
|
For reference I have already removed a lot of unused strings in J4
On 4 Aug 2017 8:42 pm, "Thomas Hunziker" <notifications@github.com> wrote:
In the past, we added a comment before the deprecated string with that
deprecation message. That comment will show up in com_localise (but not in
Crowdin).
Don't put the lines at the end of the file, keep them in the place they are.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#17409 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPH8c4sYKMu5BrkDD-Oe6EKpy5hF8SOks5sU2X9gaJpZM4OtjSS>
.
|
…er-time-zone-fix # Conflicts: # administrator/language/en-GB/en-GB.com_modules.ini # administrator/language/en-GB/en-GB.com_templates.ini
…er-time-zone-fix # Conflicts: # administrator/language/en-GB/en-GB.com_modules.ini # administrator/language/en-GB/en-GB.com_templates.ini
|
Just keeping the original string (with its constant) in the ini file makes no sense. |
That is exactly what has been done in the past at your insistence (there are many examples of this)
There is no B/C break as it is a new string that is being used. We are only keeping the old string available because of your insistence that it could be being used by a third party. (there are many examples of this) |
|
To me to keep the old string is silly if it's not used in the core and it's not a JGLOBAL string. It doesn't break anything and just looks a little ugly should someone be using a core component string which means they know they are doing it and can release a fix using the new string.
…On 5 Aug 2017, 07:41 +0100, Brian Teeman ***@***.***>, wrote:
> Just keeping the original string (with its constant) in the ini file makes no sense.
That is exactly what has been done in the past at your insistence (there are many examples of this)
> This will not be B/C because the original constant is not used anymore in the xml.
There is no B/C break as it is a new string that is being used. We are only keeping the old string available because of your insistence that it could be being used by a third party. (there are many examples of this)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@tonypartridge agreed but thats what has been demanded in the past. i spent ages removing those unused strings for j4 |
|
@mbabker I call for change! Any non JGLOBAL strings can be removed if not used in the core.
…On 5 Aug 2017, 07:47 +0100, Brian Teeman ***@***.***>, wrote:
@tonypartridge agreed but thats what has been demanded in the past. i spent ages removing those unused strings for j4
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
My mistake, sorry indeed. Not awaken this morning... It is true that lang packages can be updated (as they are proposed for any 3.x J version) while the J version is not and therefore the reason why we should keep old strings and deprecate them, JGLOBAL or NOT. In this specific case though, the change in the value is small and keeping the same constant would be enough while changing the value imho. |
|
Whilst I agree with the change of the value and not the string people wouldn't be happy with the inconsistency for translations etc.
…On 5 Aug 2017, 10:26 +0100, infograf768 ***@***.***>, wrote:
> There is no B/C break as it is a new string that is being used. We are only keeping the old string available because of your insistence that it could be being used by a third party. (there are many examples of this)
My mistake, sorry indeed. Not awaken this morning...
It is true that lang packages can be updated (as they are proposed for any 3.x J version) while the J version is not and therefore the reason why we should keep old strings and deprecate them, JGLOBAL or NOT.
In this specific case though, the change in the value is small and keeping the same constant would be enough while changing the value imho.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
There will always be inconsistencies in translations, (as well as in the en-GB reference language files). 1.TTs are volunteers and may or may not update their packs in time for a release + some disappear after a few major version packs. We should nevertheless keep as many languages as we can for the final users. 4.0 will be the occasion for a good cleaning and start from scratch for many languages, as we did after 1.5 and 2.5. |
|
Oh god at this rate I'll close the PR 😂.
Can we just get an official verdict on what's right
…On 5 Aug 2017, 11:09 +0100, infograf768 ***@***.***>, wrote:
There will always be inconsistencies in translations, (as well as in the en-GB reference language files).
It is good to correct as much as we can and do our best while we modify the en-GB in core.
1.TTs are volunteers and may or may not update their packs in time for a release + some disappear after a few major version packs. We should nevertheless keep as many languages as we can for the final users.
2. Also, as Brian wrote, 3pd may be using some existing strings in their extensions (in fact we should encourage them to do that more...), and not only lib or global ones
4.0 will be the occasion for a good cleaning and start from scratch for many languages, as we did after 1.5 and 2.5.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
What you have now is correct
…On 5 Aug 2017 12:43 pm, "Tony Partridge" ***@***.***> wrote:
Oh god at this rate I'll close the PR 😂.
Can we just get an official verdict on what's right
On 5 Aug 2017, 11:09 +0100, infograf768 ***@***.***>, wrote:
> There will always be inconsistencies in translations, (as well as in the
en-GB reference language files).
> It is good to correct as much as we can and do our best while we modify
the en-GB in core.
> 1.TTs are volunteers and may or may not update their packs in time for a
release + some disappear after a few major version packs. We should
nevertheless keep as many languages as we can for the final users.
> 2. Also, as Brian wrote, 3pd may be using some existing strings in their
extensions (in fact we should encourage them to do that more...), and not
only lib or global ones
> 4.0 will be the occasion for a good cleaning and start from scratch for
many languages, as we did after 1.5 and 2.5.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#17409 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPH8R3iJs0lXNFevOPN6WuRVYnN40pBks5sVEc0gaJpZM4OtjSS>
.
|
* staging: (148 commits) Correcting non-escaped double quotes in en-GB.plg_sampledata_testing.ini (joomla#17455) Correct namespace reference (Fix joomla#17448) Correcting Jalali/Persian calendar popup (joomla#17432) Adding russian calendar language file (joomla#17443) Reset for dev Prepare 3.8 Beta release Fix covers tags Fix file paths Move library files to just libraries/src as it should be (joomla#17441) Add a default empty array for the session queue (joomla#16943) [3.8] Restructure version constants (joomla#16169) Adjusting copyright and versions and two remaining "sampledata" (joomla#17435) PHP 7.2 has branched, update Travis config to reflect PHP 7.2 count warning (joomla#16840) Enforce array for subform values (joomla#16733) System URL menu link (joomla#17419) Don't use array merge here. (joomla#17391) add the checked attribute (joomla#17336) [RFC] Mod sample data (joomla#7680) Rename Page to Menu Item (joomla#17409) ...
* staging: (148 commits) Correcting non-escaped double quotes in en-GB.plg_sampledata_testing.ini (joomla#17455) Correct namespace reference (Fix joomla#17448) Correcting Jalali/Persian calendar popup (joomla#17432) Adding russian calendar language file (joomla#17443) Reset for dev Prepare 3.8 Beta release Fix covers tags Fix file paths Move library files to just libraries/src as it should be (joomla#17441) Add a default empty array for the session queue (joomla#16943) [3.8] Restructure version constants (joomla#16169) Adjusting copyright and versions and two remaining "sampledata" (joomla#17435) PHP 7.2 has branched, update Travis config to reflect PHP 7.2 count warning (joomla#16840) Enforce array for subform values (joomla#16733) System URL menu link (joomla#17419) Don't use array merge here. (joomla#17391) add the checked attribute (joomla#17336) [RFC] Mod sample data (joomla#7680) Rename Page to Menu Item (joomla#17409) ...
Pull Request for Issue #17408 .
Page is not a word natively used in Joomla! we should stick to standard convention of Menu Item.