• I have tested successfully.
• 

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11935.}

I have tested this item ✅ successfully on d8f99f0

I have tested this item ✅ successfully on d8f99f0

RTC

I have tested this item ✅ successfully on d8f99f0

I'm not keen on labeling it "Associations" . On the webmaster side, "content association" is well intended but for a visitor, I think "Translations" would be more easy to understand. (Of course you can change that on your site, but I think sensible defaults are important).

That's a very good point

Associated items may not always be translations.

We could neutralise this. Would you simply prefer
JASSOCIATIONS=">"

I'm quite ok with your solution. However what about ""Also available: ".

As long as I have at least 2 people agreeing with anyhting, I will change. ?

I am not a fan of just having > it looks like a debug error that someone had an extra > in their code

When is an association not a translation? I can't see that scenario.

When is an association not a translation? I can't see that scenario.

The demo multilingual site demonstrates that:
An article concerning Shakespeare in English can be linked to an article concerning Federico Garcia Lorca in Spanish.

This is the great advantage of this system: it can or not be a translation.
This has been explained since 1.6...

So, would Also available: be OK for you?

sorry i understand what you mean now - needed more coffee

I would read your suggestion as "Also available in spanish"
So if you are happy that this doesnt suggest a translation then go for it

It would be:
Also available: (flags or sef)

yes I got that - what I was saying is that as a user I would read the output as meaning "Also available in spanish"

If you are happy with your proposal meaning that to me then I am happy with the string

No, for me, It would not mean Also available IN some language.
It would mean Also available: This in some language

If that is unclear in English, then we should find something else

Both those sentences mean the exact same thing to me

On 6 September 2016 at 09:06, infograf768 notifications@github.com wrote:

No, for me, It would not mean Also available IN some language.
It would mean Also available: This in some language

If that is unclear in English, then we should find something else

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11935 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8RJ2kpNTKOTz61jwMe8P_Ct0UbWiks5qnR8cgaJpZM4J075J
.

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

Done, thanks for feedback.

Thanks - no need for new tests as it was just a language string change - this is good for merge in 3.7

Great new feature - thanks everyone

@infograf768 Thank you Jean-Marie. I had to remove the RTC label due to the wrong usage of JRoute in the helper class. Please check the Gist how the code should look like properly: https://gist.github.com/Kubik-Rubik/901591e750e26ad9a0ca3fe0a9a08112 Can you please update your PR?

@Kubik-Rubik
Thanks for feedback and suggestions. Corrected.

Please folks, test again.
@bhavikTailored
@AnishaTailored
@brianteeman
@alexgarel

I have tested this item ✅ successfully on 7cb21c4

on current 3.7.0 branch

we need one more tester here.

I have tested this item ✅ successfully on 7cb21c4

looks good here on protstar and with multilanguage ;) Thanks

Thanks for testing. Back to RTC.

I am removing the RTC for now. After applying the PR in the 3.7 branch the time/date is broken as can be seen in this screenshot

I do not see how this PR would have any impact on the time/date. It does not touch anything even far related to this.

Back to RTC.

@brianteeman

I tested on a clean 3.7.0 and all is fine here. I guess you have an issue on your test site related to calendar.

I tested on a clean 3.7 - it worked fine before the PR - it broke after the
PR

I repeated it three times to confirm

On 13 September 2016 at 08:51, infograf768 notifications@github.com wrote:

Back to RTC.

@brianteeman https://github.com/brianteeman

I tested on a clean 3.7.0 and all is fine here. I guess you have an issue

on your test site related to calendar.

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11935 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8SumGpb78IRTDSUpjWtCJwRGgxgQks5qplYfgaJpZM4J075J
.

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

i have no idea how you applied the pr but be aware that there is a small conflict for one of the xmls on 3.7. when i test, i patch with eclipse and get rid of the conflict

Sorry I thought I uploaded this movie yesterday showing the effect on the date with and without the patch - Note github does not indicate there are any conflicts

hmm i can confirm this issue :( Also with 3.6.3-dev after applying this patch with patchtester.

@infograf768 can you sync to staging (there should be a button on github)?

You mean sync with 3.7 ? There is no conflict on staging.
Which php versions are you using?
As I said, this patch does not touch, even from far away anything related to date: just look at the code.

Folks, I confirm the issue when using patchtester, not with applying the patch in Eclipse after correcting the small issue with an xml

On a 3.7.0, using git apply I get:
macbookpro-2:infograf768 mac$ curl https://patch-diff.githubusercontent.com/raw/joomla/joomla-cms/pull/11935.patch | git apply
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 24425 0 24425 0 0 11511 0 --:--:-- 0:00:02 --:--:-- 15246
:76: trailing whitespace.

:98: trailing whitespace.
JGLOBAL_SHOW_ASSOCIATIONS_DESC="Multilingual only. If set to Show, the associated articles flags or URL Language Code will be displayed."
:314: trailing whitespace.

error: patch failed: components/com_content/views/article/tmpl/default.xml:132
error: components/com_content/views/article/tmpl/default.xml: patch does not apply

Therefore I think Patchtester is messing with it.
Will create a new PR towards 3.7.x

Therefore I think Patchtester is messing with it.

Unlikely

On 15 September 2016 at 09:21, infograf768 notifications@github.com wrote:

Folks, I confirm the issue when using patchtester, not with applying the
patch in Eclipse after correcting the small issue with an xml

On a 3.7.0, using git apply I get:
macbookpro-2:infograf768 mac$ curl https://patch-diff.
githubusercontent.com/raw/joomla/joomla-cms/pull/11935.patch | git apply
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 24425 0 24425 0 0 11511 0 --:--:-- 0:00:02 --:--:-- 15246
:76: trailing whitespace.

:98: trailing whitespace.
JGLOBAL_SHOW_ASSOCIATIONS_DESC="Multilingual only. If set to Show, the
associated articles flags or URL Language Code will be displayed."
:314: trailing whitespace.

error: patch failed: components/com_content/views/
article/tmpl/default.xml:132
error: components/com_content/views/article/tmpl/default.xml: patch does
not apply

Therefore I think Patchtester is messing with it.
Will create a new PR towards 3.7.x

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11935 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8ddWoCV2foR2dY073T8ude8dd8Peks5qqQAVgaJpZM4J075J
.

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

I was right. Anyway... Closing this in favour of #12042

@mbabker
There was an adaptation to do for 3.7 in this PR, which I did in #12042
I had no issue with Eclipse and using Guess to patch fine a 3.7 locally.
It looks like patchtester has issues in this case.
Usually, such small conflicts are solved by maintainer when merging stuff to another branch but some testers only rely on patchtester and do not inspect the code.
Anything that can be done in such a case for patchtester?

Trying to close again...

@zero-24
Can you force close this?

OK, looks like it worked from this side. bot is idiot... ?

Patch tester does not patch files, it does a 1-for-1 replacement (backing up the file as it exists on your local filesystem then downloading the file as it exists in the remote branch the pull request is based off when applying then deleting the downloaded file and restoring the backed up original on revert).

So even though it is a "patch" tester, it does not test by "patching" files. As a CMS install doesn't have the requisite git information it'd be pretty difficult to compute proper patches for every scenario.