@pe7er can you resolve the merge conflicts?

Merge conflict fixed...

Thanks RTC

Travis did not like this PR regarding PHP 5.6 (he's happy with 5.3 to 5.5).
I don't understand the problem. Can someone correct this error? Thanks!

Travis did not like this PR regarding PHP 5.6 (he's happy with 5.3 to 5.5).

Just beacause of a seccond change ;)

Catching of the expeced result was at: 2015-08-26 09:22:05 and the actual result is 2015-08-26 09:22:06

So all is good here. I try to bring it up to the Unit Tester Group to find a better way to test.

Ok, thanks @zero-24

I know PHPUnit has a way to test values with a variance for pure integers, I don't know if it can do the same natively for date/time values. Either way I'd call that a fluke (and re-ran the job). Definitely something to dig into though.

@pe7er

Could you make a list of all the language strings that became obsolete in your various recent patches?
We can't take the strings out now as the lang packs may be used in older J version but this will be useful for J! 4 in order to take them off.
@Bakual
Maybe create a specific github repository where these will be available for the future?

Maybe create a specific github repository where these will be available for the future?

Why would you want to make them available separately? They will stay in J3 until it's EOL, and in J4 they will be removed. So they will be available in the 3.x branch/latest release.
Similar to how the 2.5.x branch is still available.

It is not to make them available, just the opposite.
The reason is that it will be easier to delete all these when 4.0 is prepared.
Keep trace of all these easily.

I would rather add a deprecate notice to the string into the file itself.

I found out that when we add them after the string like this:
COM_FOO_BAR="Bar" ; This string is deprecated and will be removed with Joomla 4.0
Then it will even show up in translation tools like Crowdin (and probably also Transifex). Which means newly created language packs could actually skip translating those.

I hope someone also tested this on Hathor

It would be much easier to have a list of all obsolete strings per file, just delete them in en-GB when we get to 4.0 and let TTs delete them the way they wish (I know that, for me, it will be much easier to delete manually with BBEdit than with any app including com_localise.)

Also

I found out that when we add them after the string like this:
COM_FOO_BAR="Bar" ; This string is deprecated and will be removed with Joomla 4.0

This would mark the file as errored in com_localise. When using comments, they should be on their own line.

It would be much easier to have a list of all obsolete strings per file, just delete them in en-GB when we get to 4.0 and let TTs delete them the way they wish (I know that, for me, it will be much easier to delete manually with BBEdit than with any app including com_localise.)

It may be easier for manual workflows, but it's much more work for the maintainers.
Also tools like Crowdin and Transifex will remove them automatically if we remove them in source.

This would mark the file as errored in com_localise. When using comments, they should be on their own line.

Joomla doesn't has a problem with it and com_localise can be adjusted.

So, this one should be closed.
#6958

Thanks @bertmert. This one can be closed now...