Sadly yes it is

Well, excuse my French, but it's a load of ?

it is indeed

COM_CATEGORIES_TIP_ASSOCIATED_LANGUAGE="%s %s"
COM_CONTACT_TIP_ASSOCIATED_LANGUAGE="%s %s (%s)"
COM_CONTENT_TIP_ASSOCIATED_LANGUAGE="%s %s (%s)"
COM_CONTENTHISTORY_COMPARE_VALUE1="Saved on %s %s"
COM_CONTENTHISTORY_COMPARE_VALUE2="Saved on %s %s"
COM_MENUS_TIP_ASSOCIATED_LANGUAGE="%s %s (%s)"
COM_NEWSFEEDS_TIP_ASSOCIATED_LANGUAGE="%s %s (%s)"

These are the most ambiguous but there are others which are pretty close

99b02d0

ALL OF THOSE TIP_ASSOCIATED STRINGS HAVEN'T EXISTED FOR FOUR &@!&ING YEARS!

@infograf768 @Bakual The translation policy needs to be addressed sooner than later.

lol

Did you have a look what is being passed there?

The TIP_ASSOCIATED_LANGUAGE strings were all removed in the commit I linked 4 years ago. So nothing is being passed to them because nothing is using them.

Ah, didn't understand that comment while on my mobile.
I fully agree we need to adjust that policy. I'm not sure if it makes sense to change it for the 3.x series anymore, but for 4.0 we need a better plan for sure (if it can be applied to 3.x as well, even better).

Imho the current policy comes mainly from the fact that language packs made for 3.7.0 can also be installed in any Joomla 3.x version. And updates are propagated for that newer language pack even on outdated Joomla versions. If we remove strings, they end up with untranslated keys.
The solution to that is "simple":

• We need to make sure a 3.7.0 language pack can't be installed in 3.6 and earlier.
• We need to make sure a 3.7.0 pack isn't propagated as update for Joomla 3.6 and earlier.

Both is technically already possible and we do it in 3rd party extensions for a long time already using a script.php in the package and targetplatform attribute in the update XML. However the script.php is a bit to technical for translators I'm afraid.

• If #13789 gets merged, we could simply use the versio attribute to specify the minimum Joomla version. That would prevent installing into lower versions.
• The targetplatform would have to be set when the package is uploaded to JC or its successor downloads.joomla.org. I don't think it makes sense to adjust anything on JC at all, but for the new site it would make perfectly sense to use it. I just don't know how far that one is for language packages.

Concerning the strings with
_TIP_ASSOCIATED_LANGUAGE

I think they can safely be deleted as no code uses it since 3.1.4. (or maybe even 3.1.2)

Removing them goes against our current language policy

I know the policy...
We could do an exception for these as I doubt that anyone is using a pre-3.1.4 Joomla.
And if someone does, that would be a very good sign it is time to update. These tips were only used in the associations column to edit directly an associated item. We now use a very different way.

Concerning the usage of multiple %s in a string value, most of the time they have been done by patchers that did not care about translation by ignorance or specially not care about non-English languages by (choose a word here).
I have also merged in the past some of these by mistake or just because I forgot to check (who can throw the first stone?)
At least using %1$s etc. is better.
Alas also, any comment before the string to explain "which variable is used for what" is not always displayed, depending on the tools used by the Translator. It therefore is not sufficient to inform the TT.
Not a simple issue to solve.

I am not in favour of making this exception

The whole point is they were never marked in the language files as unused and fact is even if they were still used it would be next to impossible to know what value goes where without getting into the code. So sprintf keys should be better documented.

So we kind of started talking about this earlier today here in Krakow, and we're in a bit of a "funny" situation. Since roughly 3.2, JText has supported a couple of different syntaxes for sprintf operations through JText::_() and JText::sprintf() (#880 and #1597 for reference). In the Framework version 2 package, we handle the notion of named parameters a bit differently in the PHP API, which affects the use in language strings as well, as a practical demo:

SOME_STRING="Hello [[%1:name]], Welcome to [[%2:sitename]]. You can log in with [[%3:username]] ([[%4:password]])"

versus

SOME_STRING="Hello %name%, Welcome to %sitename%. You can log in with %username% (%password%)"

With what's in the CMS now, if I'm not mistaken, the custom syntax works for both JText::_() and JText::sprintf() whereas with the Framework code you have to call Text::translate() with the string and a separate array of parameters to replace (it's not a sprintf).

Either way, the use of named parameters would be helpful to this process. The question starts to boil down to how do we want to approach it.

i would definitely be in favour of a named parameter and i am sure translators would be as well. it will make life so much easier especially in languages where the order of words is different than in english.

from looking at the two options you show the main difference is if you have a number in there or not. If we are using real words then I dont see the need myself to have the number as well.

Personally I think the current code is more complex, but I think it is also
designed for scenarios where it is harder to call things the "right" way
(right being very subjective).

So we'd really need to look through how the current implementation works
and figure out if there is a way to transition it to the simpler logic in
the Framework. The one con to that though is that sprintf loses named
parameter support, anything using named parameters would have to pass
through our underscore method and the sprintf method basically goes back to
just wrapping PHP's implementation without extra logic.

On Mon, May 29, 2017 at 2:21 PM Brian Teeman notifications@github.com
wrote:

i would definitely be in favour of a named parameter and i am sure
translators would be as well. it will make life so much easier especially
in languages where the order of words is different than in english.

from looking at the two options you show the main difference is if you
have a number in there or not. If we are using real words then I dont see
the need myself to have the number as well.

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

--

• Michael Please pardon any errors, this message was sent from my iPhone.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/14555

closed as having Pull Request #18202