hmm would't language string support help here too so you set PLG_SYSTEM_FOO_UPDATEXML_DESCRIPTION or similiar?

Maybe the different languages can be provided as JSON string or similiar. I would not go the route to do another request as that multiplies per installed extension.

So something like this:

<description>{de-DE: "Das ist ein Test", en-GB: "This is a test"}</description>

Anothoer one could look like:

<description language="de-DE">Das ist ein Test</description>
<description>This is a test</description>

Where without any is interpreted as en-GB as right now.

@zero-24

My method is better because:

• backward compatible with current system and static XML files
• no major code re-writes are required, just do langauge tag lookup and send with cURL request
• my method is designed for people to use a programatic system (i.e. joomla component) at the other end to facilitate the response, not standalone files.
• if you handle all of the different languages in a single static front facing file like you suggest, these files would get really messy.
• with my suggestion you can use the Joomla Association/Language features
• PLG_SYSTEM_FOO_UPDATEXML_DESCRIPTION this would not help because my update server will still not know what the language is of the client who is making the request.
• my suggestion will supply the correct XML for the requested language if present or as a fallback the default language. This will all happen invisibly for the client as it will appear just as a single file.

@zero-24

My method is better because:

• backward compatible with current system and static XML files

Mine too

• no major code re-writes are required, just do langauge tag lookup and send with cURL request

Agree but one request per update server and the limit for having to use an active component in the process does not sound ideal to me.

• my method is designed for people to use a programatic system (i.e. joomla component) at the other end to facilitate the response, not standalone files.

Why should such a feature be limited to people using such a component?

• if you handle all of the different languages in a single static front facing file like you suggest, these files would get really messy.

Well it can be i agree. That system was in the first place not designed for multilanguage. Another way around could be that all fields can be a URL too and that is fetched for the language strings.

• with my suggestion you can use the Joomla Association/Language features

What features do you mean i can not follow you on that point.

• PLG_SYSTEM_FOO_UPDATEXML_DESCRIPTION this would not help because my update server will still not know what the language is of the client who is making the request.

Agree. The idea was to have a fixed message that can be translated using language files supplied with the plugin.

• my suggestion will supply the correct XML for the requested language if present or as a fallback the default language. This will all happen invisibly for the client as it will appear just as a single file.

Ok.

One additional question what kind of information is passed via that kind of field on your side? Could it be handled via the 4.x changelog feature that would have to be made multilingual too i guess.

see my 1st post for examples of what can be translated.

the changelog i left out tue discussion be it would be complicated to translate and i doubt any developer would want to.

see my 1st post for examples of what can be translated.

But thats a static text right? Different per language but static per extenstion right?

the changelog i left out tue discussion be it would be complicated to translate and i doubt any developer would want to.

Well the idea would be one URL per language. But i agree that change logs are hard to translate.

• those items are static text.

• it would be a single url for all languages with my system.

• if you use static files then you could use htaccess or stick with a single language.

those items are static text.

Great. So I would suggest to go the "allow translation strings" route.

Allowing the two fields to be a language strings that get translated using JText.
That strings would than be similiar to the install XML texts already allowed to be language strings.
Should be as easy as adding two ´JText::_()` calls here: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/views/update/tmpl/default.php#L96-L97
and load the language files of the extensions that have updates aviable.

That would be B/C, aviable to everyone, does not involve many code nor any generation logic on the remote site.

What do you think? Given that such texts are there already this change would make that in sync with the other places where we use the name and description of extensions.

@zero-24

I am not sure what you are trying to do here. But it will not fix my issue/feature request, it is simply not possible because the request does not have the Accept-Language: <language> header so my Joomla update server does not know what language is being requested.

If you mean I should store this information within the extension, then this is a bad idea. The update server should be the update server. The information on the update server changes dynamically and therefore should never be stored in the extension.

I would have a Joomla component handling this and a simple mockup of the backend would be:

Below you can see my examples. The same stream, same location, different output.

Default / English version

Update stream: https://quantumwarp.com/updates/joomla/qwdemobar/update.xml

This would the stream sent back if no matching language header is sent or if no language header is sent

<?xml version="1.0" encoding="UTF-8"?>
<updates>
	<update>
		<name>QWDemoBar</name>
		<description>Showcase your product range in this highly configurable responsive toolbar.</description>
		<element>qwdemobar</element>
		<type>component</type>           
        <client>1</client>
		<version>1.0.0</version>
		<infourl title="QWDemoBar v1.0.0 Release">https://quantumwarp.com/projects/joomla/qwdemotoolbar</infourl>
		<downloads>
			<downloadurl type="full" format="zip">https://github.com/shoulders/QWDemoBar/releases/download/v1.0.0/com_qwdemobar-v1.0.0.zip</downloadurl>
		</downloads>
		<tags>
			<tag>stable</tag>
		</tags>
		<sha256>e44613a77ee69d1139e790edb488d88f603419041167fa0b7f17c5dd49e6bacd</sha256>
		<sha384>1ad7535c4bce8c296270151b856fee5293329024779f5514e892fcd58937256d0f16b6c65ac77766377b16f34ce3ba19</sha384>
		<sha512>29ee383795f8787402665e822f3be27649a9a2b2d81118ec7cdc0e077d90a8f41c0ca8b6343d0a8eb218d83e3daf420b8a87969a759c1e54e6794519d6f00bc6</sha512>
		<maintainer>QuantumWarp</maintainer>
		<maintainerurl>https://quantumwarp.com</maintainerurl>
		<section>Updates</section>
		<targetplatform name="joomla" version="3.*"/>
		<php_minimum>5.3.10</php_minimum>
        <supported_databases mysql="5.5.3" mariadb="10.1" />
	</update>
</updates>

French Version

Update Stream https://quantumwarp.com/updates/joomla/qwdemobar/update.xml

My idea is, if you are in France and your french Joomla site access this update stream you would get the following XML.

The header Accept-Language: fr-FR will be sent with the request to this URL

Notice how only the description and the infourl are changed. There are no untranslated strings and as far as the Joomla installation requesting the update XML, it got it, and in particular it got the french one necaise it have the Accept-Language: fr-FR header.

<?xml version="1.0" encoding="UTF-8"?>
<updates>
	<update>
		<name>QWDemoBar</name>
		<description>Présentez votre gamme de produits dans cette barre d'outils réactive hautement configurable..</description>
		<element>qwdemobar</element>
		<type>component</type>           
        <client>1</client>
		<version>1.0.0</version>
		<infourl title="QWDemoBar v1.0.0 Release">https://quantumwarp.com/projects/joomla/qwdemotoolbar/fr-FR</infourl>
		<downloads>
			<downloadurl type="full" format="zip">https://github.com/shoulders/QWDemoBar/releases/download/v1.0.0/com_qwdemobar-v1.0.0.zip</downloadurl>
		</downloads>
		<tags>
			<tag>stable</tag>
		</tags>
		<sha256>e44613a77ee69d1139e790edb488d88f603419041167fa0b7f17c5dd49e6bacd</sha256>
		<sha384>1ad7535c4bce8c296270151b856fee5293329024779f5514e892fcd58937256d0f16b6c65ac77766377b16f34ce3ba19</sha384>
		<sha512>29ee383795f8787402665e822f3be27649a9a2b2d81118ec7cdc0e077d90a8f41c0ca8b6343d0a8eb218d83e3daf420b8a87969a759c1e54e6794519d6f00bc6</sha512>
		<maintainer>QuantumWarp</maintainer>
		<maintainerurl>https://quantumwarp.com</maintainerurl>
		<section>Updates</section>
		<targetplatform name="joomla" version="3.*"/>
		<php_minimum>5.3.10</php_minimum>
        <supported_databases mysql="5.5.3" mariadb="10.1" />
	</update>
</updates>

does this clear things up?

I got your point now. I have just requested the @joomla/cms-maintainers to give thier opinions here too. Maybe we can even go with both solutions. (Adding the language in the request and allow them to be language strings).

Ps the client value should be administrator or site and not an integer any more. That integer handling is removed from 4.x+

thanks for the <site>0</site> ? This is just a quick demo xml I had to hand. I have been doing a lot of work/research on the update procedure and this language thing got flagged up. FYI I am going to write an update server as a joomla component that follows all of the standards etc... so us amateur can set up an update server much easier.

Sounds like a plan. I would not recommend language strings in the update stream. But I am open to other points of view.

I just made a quick diagram just incase my point of view was not made and it seems a shame to waste this piece of art ?

Sounds cool feel free to reache out to me via tobias.zulauf[at]cjo when there are additional questions etc. I'm also interested to hear your opinion on how we could improve our docs to make it easier to understand. But lets focus here on that language thing and do the other stuff via mail.