Disagree as stated in #9234 it is just plain daft to do anything to support
old, outdated, insecure and vulnerable versions of joomla
On 28 Feb 2016 7:33 am, "infograf768" notifications@github.com wrote:

Reverting #9234 #9234 and
changing the toolbar titles to use parenthesis instead of hyphen.
Cache, Installed languages and Modules concerned
As in #9234 #9234 we will get
(here for Modules)
[image: screen shot 2016-02-28 at 08 31 15]

https://cloud.githubusercontent.com/assets/869724/13378030/c7800df4-ddf5-11e5-8929-624e706c9b6a.png

You can view, comment on, or merge this pull request online at:

#9239
Commit Summary

• regression #9234 Modifying strings to use ()

File Changes

• M administrator/components/com_cache/views/cache/view.html.php https://github.com/joomla/joomla-cms/pull/9239/files#diff-0 (11)
• M administrator/components/com_languages/views/installed/view.html.php https://github.com/joomla/joomla-cms/pull/9239/files#diff-1 (13)
• M administrator/components/com_modules/views/modules/view.html.php https://github.com/joomla/joomla-cms/pull/9239/files#diff-2 (13)
• M administrator/language/en-GB/en-GB.com_cache.ini https://github.com/joomla/joomla-cms/pull/9239/files#diff-3 (4)
• M administrator/language/en-GB/en-GB.com_languages.ini https://github.com/joomla/joomla-cms/pull/9239/files#diff-4 (4)
• M administrator/language/en-GB/en-GB.com_modules.ini https://github.com/joomla/joomla-cms/pull/9239/files#diff-5 (3)

Patch Links:

• https://github.com/joomla/joomla-cms/pull/9239.patch
• https://github.com/joomla/joomla-cms/pull/9239.diff

—
Reply to this email directly or view it on GitHub
#9239.

Reason :
#9234 is not B/C. The policy is to not modify strings that can be used by older versions (3.4.8 is not so old that everybody will move to 3.5.0...).
It would be OK if the modification of the string value was typo/better english or better explanation of a tip, but in this case was introduced in the value a new variable with parenthesis.

On a pre-350 one would get:
Languages: Installed ()

If they won't upgrade joomla why would they upgrade the language
On 28 Feb 2016 7:39 am, "infograf768" notifications@github.com wrote:

Reason :
#9234 #9234 is not B/C. The
policy is to not modify strings that can be used by older versions (3.4.8
is not so old that everybody will move to 3.5.0...).
It would be OK if the modification of the string value was typo/better
english or better explanation of a tip, but in this case was introduced in
the value a new variable with parenthesis.

On a pre-350 one would get:
Languages: Installed ()

—
Reply to this email directly or view it on GitHub
#9239 (comment).

If they won't upgrade joomla why would they upgrade the language

People do that all the time, and not only for languages...

This matter has already been discussed and this is our policy to be B/C concerning language strings and the reason why we do not delete strings that are no more used in recent 3.x versions.

In this case, we should consider the modification to the existing strings to be similar as the value is heavily changed.

From the Backwards Compatibility Policy: https://developer.joomla.org/cms/development-strategy.html#backward_compatibility

"Changing or deleting a language key is considered a backwards compatibility break. Adding new ones is not. Substantially changing the meaning associated with a language key is a compatibility break. Rephrasing something for a more accurate description or proper en-GB grammar is not."

Adding the value in parentheses sounds like a "more accurate description" to me.

for me is ok, i asked that in the PR. because i was not sure i could do that change.

@chrisdavenport
I disagree. It adds a variable between parenthesis and It is rather:
"Substantially changing the meaning associated with a language key is a compatibility break."

as it will change the display to show empty parenthesis on a pre 3.50.0 site
Languages: Installed ()

How is adding "()" changing its meaning?

It is adding a variable that was not there before, Chris.
The solution is simple and in this PR: going back to the first implementation and just changing the hyphen to parenthesis for the strings concerned (new strings)
What is so hard to understand here? A UX with empty parenthesis is just ugly and meaningless.

Okay, I think I understand now.

Adding the variable is not the issue; the issue is adding the parentheses.

The coder in me would always prefer adding a variable rather than hard-coding the strings. So why not leave the existing string alone for use by pre-3.5 installations, but add a new string which includes the variable for use by 3.5+? If someone installs a later language pack onto a pre-3.5 Joomla it would still use the old string. The old string can be deprecated for removal in 4.0.

I have tested this item successfully on 088cc09

Works fine. Solves the possible B/C issue with language variable.

One comment for future consideration.
Why is a user allowed to install/update a language pack with a version greater than his Joomla installed version?
If Joomla blocks installing language packs greater then is version (in installation, extensions -> install languages and extensions -> update) i think this problem would not even exist, right?

Backwards Compatible

A new version of a program http://www.webopedia.com/TERM/P/program.html is
said to be backward compatible if it can use files and data created with an
older version of the same program.

Here we are being asked to do the opposite. We are being asked to not make
a change in version x+1 so that it will work in version x or even version
x-1

That is not being "backwards compatible". It is beyond my comprehension
that we would ever not do something in version x+1 because someone choses
not to upgrade to that version. We spend so much time telling people that
the MUST upgrade why are we even considering doing something to support the
people that do not upgrade. (Not even considering the ludicrous scenario of
someone NOT upgrading Joomla but DOES upgrade the language file. - Sorry
but that is just plain daft and if someone does do that then why should we
care)

On 28 February 2016 at 10:19, andrepereiradasilva notifications@github.com
wrote:

I have tested this item [image: ] successfully on
088cc09
088cc09

Works fine. Solves the possible B/C issue with language variable.

One comment for future consideration.
Why is a user allowed to install/update a language pack with a version
greater than is Joomla installed version?
If Joomla blocks installing language packs grater then is version (in
installation, extensions -> install languages and extensions -> update) i

think this problem would not even exist, right?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/9239
https://issues.joomla.org/tracker/joomla-cms/9239.

—
Reply to this email directly or view it on GitHub
#9239 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@chrisdavenport
Thanks for understanding. What you may not be aware of is that I had chosen specifically to use 2 new strings instead of a sprintf with variable (and therefore one new string only) for these 3 just merged PR (in the last week) concerning toolbar title, i.e.

COM_LANGUAGES_VIEW_INSTALLED_ADMIN_TITLE="Languages: Installed - Administrator"
COM_LANGUAGES_VIEW_INSTALLED_SITE_TITLE="Languages: Installed - Site"

COM_MODULES_MANAGER_MODULES_ADMIN="Modules - Administrator"
COM_MODULES_MANAGER_MODULES_SITE="Modules - Site"

COM_CACHE_CLEAR_CACHE_ADMIN_TITLE="Maintenance: Clear Cache - Administrator"
COM_CACHE_CLEAR_CACHE_SITE_TITLE="Maintenance: Clear Cache - Site"

They were using an hyphen.
It was proposed to use parenthesis instead of the hyphen, as I had just done for com_menu items, which I agreed.
Therefore the new PR just needed to change the hyphen to parenthesis in the newly created strings.

@andrepereiradasilva
Let me explain the scenario:
A user has set up a 3.4.8 site with all its extensions, languages, etc.
It works fine.
3.5.0 is released.
The user prefers to wait 3.5.1 or later (to let the new version iron out possible bugs or let the 3rd party extensions he uses update) to create any new site as he knows all his settings work fine in 3.4.8.
Therefore he will create a 3.4.8 site and when adding the language, he will find a 3.5.0.1 language to install. The language pack has to be B/C with 3.4.8.

Now, about the version of the language pack proposed.
Let's say the only pack available for a specific language is a 3.2.x as it was not updated (Translation Team absent, no time to update pack which will be proposed later on, whatever), but the user needs that language.
If we were proposing via the cron job only the version of the language pack corresponding to the Joomla version, the user would not be able to install the language 3.2.x version on a 3.4.8 or 3.5.0.
Letting the user install even a somehow obsolete pack lets use the language overrides for the absent or changed strings absolutely needed on the site (mostly frontend usually).

I've said this before and I'll say it again. To "fix" this, the cron job building the XML files needs to get smarter. Older language packs are OK on newer CMS releases (especially with English always loaded now). Newer language packs on older CMS releases shouldn't be allowed (at least by the XML files, folks could still get around it by going to the source, downloading the package, and installing it, but they're making their own lives miserable if they're going through all that work). PRs are welcome on https://github.com/joomla-projects/language-update-xml-generator

Let me explain the scenario:
A user has set up a 3.4.8 site with all its extensions, languages, etc. It works fine. 3.5.0 is released. The user prefers to wait 3.5.1 or later (to let the new version iron out possible bugs or let the 3rd party extensions he uses update) to create any new site as he knows all his settings work fine in 3.4.8.

Yes, i understod the problem you described in this PR. Thanks for explaining. i marked as sucesfully.

Therefore he will create a 3.4.8 site and when adding the language, he will find a 3.5.0.1 language to install. The language pack has to be B/C with 3.4.8.

I just don't understand why propose HIGHER language packs version than the user installed Joomla version. If Joomla does not proposed then, the user will not find the 3.5.0.1 language pack on a 3.4.8 joomla, so in that scenario it doesn't have to be B/C at that level. Exacly as @mbabker referred:

Newer language packs on older CMS releases shouldn't be allowed.

And:

If we were proposing via the cron job only the version of the language pack corresponding to the Joomla version, the user would not be able to install the language 3.2.x version on a 3.4.8 or 3.5.0. Letting the user install even a somehow obsolete pack lets use the language overrides for the absent or changed strings absolutely needed on the site (mostly frontend usually).

See my previous comment.
I didn't say only the same as Joomla version, i said the same and older, just not higher, again as @mbabker refered:

Older language packs are OK on newer CMS releases (especially with English always loaded now).

I may disagree here with @mbabker as it would make it harder for users in the case I described to find out the packs needed, but let's say the new cron job is implemented: in that case we could add a Tip at the top of the Install language page, something like:
"If you do not find the language you wish to install, it may be available here http://community.joomla.org/translations.html . Be aware that it may not fit your Joomla version."

In any case, as the cron has not been changed yet, we have to follow the B/C rule.
Please @wilsonge merge this PR.

I'm not sure I'm following where you're saying my suggestion would cause an issue. In the case of 3.5.0 language packages, they would only be presented to 3.5.0 or later CMS versions. Same would apply going back to 3.2 language packs. So if a user is running 3.4.8 and was looking for a language package, they'd be displayed the last release compatible with 3.4.8 in their language (this may be a 3.2 release), but the user would NOT be offered to update to the 3.5.0 language package until after they update the CMS to that version. It's pretty similar to how most extensions define a minimum supported version in some form in their packages.

@mbabker

2 situations:
1. in 3.5.0, we are going to get a few more languages.
2. A TT has deleted all his existing packs before 3.5.0 (I see some have done this on joomlacode for former versions. I agree they should be told not to if we change the update xmls)

A user who wants to stick to 3.4.8 for any reason (and some may be good) AND add a 3.5.x language pack (depending on the situations above), would not be able to find it in the install language list.
I would not compare it to other extensions, as an obsolete language pack or an upper version pack can be modified with language overrides, if necessary.
Therefore, if the cron is changed, my suggestion for a tip on top of the page would be the best solution.
Evidently, if the pack is not B/C (the case described here), he will get into trouble and will be forced to use overrides for what is important to her/him.

We should not be supporting old versions of joomla in any way.

This is nothing to do with any definition of backwards compatibility
On 29 Feb 2016 8:11 am, "infograf768" notifications@github.com wrote:

@mbabker https://github.com/mbabker

2 situations:
1. in 3.5.0, we are going to get a few more languages.
2. A TT has deleted all his existing packs before 3.5.0 (I see some have
done this on joomlacode for former versions. I agree they should be told
not to if we change the update xmls)

A user who wants to stick to 3.4.8 for any reason (and some may be good)
AND add a 3.5.x language pack (depending on the situations above), would
not be able to find it in the install language list.
I would not compare it to other extensions, as an obsolete language pack
or an upper version pack can be modified with language overrides, if
necessary.
Therefore, if the cron is changed, my suggestion for a tip on top of the
page would be the best solution.
Evidently, if the pack is not B/C (the case described here), he will get
into trouble and will be forced to use overrides for what is important to
her/him.

—
Reply to this email directly or view it on GitHub
#9239 (comment).

I'm going to make a PLT policy after this release to the effect of what we mostly agree on that 3.5.0 packs can't be installed on lower J versions. But in the meantime as apparently TT's seem to think differently I'm going to merge this.

Sad face. Is it really the TT that think this? Have they been asked?
On 29 Feb 2016 9:25 am, "George Wilson" notifications@github.com wrote:

Merged #9239 #9239.

—
Reply to this email directly or view it on GitHub
#9239 (comment).

Thanks @wilsonge
Discussed with Mig. He is going to send a mail to TTs asking them to never delete older versions of their packs (as most of us already do). So if/when the cron is changed for 3.6.0, we will just have to add, if you agree, this Tip/Information on top of the install languages page.

Awesome. That sounds perfect to me! Thanks JM!

My take on this:

• Its OK to not show new packs for old versions.
• If users want to install old packs on top of new system or new packs on top of old system it should be their choice (manually)

Note: This should be considered only for version changes (3.5 / 3.6) and not for minor updates (3.5.0 to 3.5.1) where an alert for outdated lang packs (same as version check) should be ok