I have tested this item ✅ successfully on 37cd2f3

I have tested this item ✅ successfully on 7c342b9

I have tested this item ✅ successfully on 7c342b9

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.

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 notifications@github.com, 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 notifications@github.com, 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
.

Just keeping the original string (with its constant) in the ini file makes no sense.
This will not be B/C because the original constant is not used anymore in the xml.
Why not just keep the original constant and just change its value?

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)

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 notifications@github.com, 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 notifications@github.com, 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.

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.

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 notifications@github.com, 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).
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.

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 notifications@github.com, 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" notifications@github.com 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 notifications@github.com, 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
.