If these are going to be language strings, they should be rendered in the receiving user's language, not the language of the admin who generates this data (which may be different on a multilingual website), see the privacy component's models for how emails are dealt with for this.

Personally, I don't think they actually do need to be strings, but it should be done right if they are.

they should be rendered in the receiving user's language

Good point!

Hummm... will check this.

Also, please, always alpha order language strings. no need to separate new strings from existing ones.

Could someone explain/post a screenshot to understand what form will take these exported logs, i.e. an example where $domain is displayed?
(Sorry, I still have not been able to create a setup using Privacy by lack of knowledge).
In fact I would like to check if we should not use a sprintf here to cope with RTL languages or else.

hmm
the method asks for 2 parameters

protected function createDomain($name, $description = '')
	{
		$domain              = new PrivacyExportDomain;
		$domain->name        = $name;
		$domain->description = $description;

		return $domain;
	}

so I guess a sprintf has no utility here.

Could someone explain/post a screenshot to understand what form will take these exported logs, i.e. an example where $domain is displayed?

It is displayed in the xml file of all exported data for one user.

<?xml version="1.0"?>
<data-export>
  <domain name="actionlog" description="Logged actions of the user">
    <item>
      <id>1</id>
      <message>User Admin logged in to admin</message>
      <date>2018-09-17 18:27:46</date>
      <extension>Users</extension>
      <name>Super User</name>
      <ip_address>COM_ACTIONLOGS_DISABLED</ip_address>
    </item>
    <item>
      <id>2</id>
      <message>User Admin installed the library iC Library</message>
      <date>2018-09-17 18:29:45</date>
      <extension>Installer</extension>
      <name>Super User</name>
      <ip_address>COM_ACTIONLOGS_DISABLED</ip_address>
    </item>

...

Thank you. Understand we get an xml, but how is that xml used ?
Is it transformed in a mail text, else? Basically what is the final result for the user or admin, i.e. what will be displayed and where? Is it stored somewhere?

Not display today, only an xml file will all data (for as long as i understand the system after testing).

But using language strings may be useful later (if rendering xml data in a HTML view).
Or using an xml render software ?...

You may guess I was asking that in relation with translation.
If a non-English speaker will read such a xml, all has to be translated.

The sample code to use the correct language, as @mbabker says, is present in the admin export model

if ($userId)
		{
			$receiver = JUser::getInstance($userId);

			/*
			 * We don't know if the user has admin access, so we will check if they have an admin language in their parameters,
			 * falling back to the site language, falling back to the currently active language
			 */

			$langCode = $receiver->getParam('admin_language', '');

			if (!$langCode)
			{
				$langCode = $receiver->getParam('language', $lang->getTag());
			}

			$lang = JLanguage::getInstance($langCode, $lang->getDebug());
		}

		// Ensure the right language files have been loaded
		$lang->load('com_privacy', JPATH_ADMINISTRATOR, null, false, true)
			|| $lang->load('com_privacy', JPATH_ADMINISTRATOR . '/components/com_privacy', null, false, true);

As a similar code would be used for multiple plugins, I wonder if it would not be good to create a specific method, maybe in plugin.php, and then use the method with the $lang variable obtained in the plugins.

@mbabker @infograf768 I've just updated PR with user language parameters.

As a similar code would be used for multiple plugins, I wonder if it would not be good to create a specific method, maybe in plugin.php, and then use the method with the $lang variable obtained in the plugins.

Maybe by adding an optional third param userId to the method loadLanguage ?

Maybe by adding an optional third param userId to the method loadLanguage ?

If you're talking about in the plugin class, no. Generally, the behavior we want is to load the language files for the active user's language.

There are a few special cases where we may want to load another language so text is shown correctly for another user, such as sending emails or these data exports. IMO that doesn't warrant coupling any of the existing language loading logic with the user system. Make a separate helper function somewhere if you must. (Another issue with adding it as a param would mean you're loading that user's preferred language into your active session, whereas the code we use now ensures that a separate Language instance for each language/locale is created; we should not be loading strings for multiple languages into one Language instance beyond the existing fallback behavior)

If you're talking about in the plugin class, no. Generally, the behavior we want is to load the language files for the active user's language.

I think mainly to let it case by case as it is in this PR. ;-)
(a bit different for privacy contact, where if no userId, contact email is used)

You may guess I was asking that in relation with translation.
If a non-English speaker will read such a xml, all has to be translated.

This is a very basic example of what an export looks like.

<?xml version="1.0"?>
<data-export>
  <domain name="users" description="Joomla! users table data">
    <item id="398">
      <id>398</id>
      <name>Super User</name>
      <username>admin</username>
      <email>admin@localhost.test</email>
      <block>0</block>
      <sendEmail>1</sendEmail>
      <registerDate>2018-09-19 13:55:15</registerDate>
      <lastvisitDate>2018-09-19 13:56:23</lastvisitDate>
      <activation>0</activation>
      <params/>
      <lastResetTime>0000-00-00 00:00:00</lastResetTime>
      <resetCount>0</resetCount>
      <requireReset>0</requireReset>
    </item>
  </domain>
  <domain name="user notes" description="Joomla! user notes data"/>
  <domain name="user profile" description="Joomla! user profile data"/>
  <domain name="user custom fields" description="Joomla! user custom fields data"/>
  <domain name="user contact" description="Joomla! user contact data"/>
  <domain name="user content" description="Joomla! user content data"/>
  <domain name="user message" description="Joomla! user message data"/>
</data-export>

The bulk of it is going to be untranslated anyway as it is all related to either the XML document structure or is based on database column names. That's in part why I felt like translating the text of the name and description attributes really wasn't necessary, you're translating a couple of strings when 95% of it is going to be surrounded by a non-translatable English string or non-localized database contents (which could be in any language known to this planet's 7 billion human inhabitants).

@mbabker
I guess I just do not understand the use of this export then.
In that case, translating is indeed useless.

To fulfill the GDPR related right to request your data, we provide this data in a XML format to allow the most portability for that data (as XML can be easily machine parsed if you want to do something programmatically with it, or read by a human in its basic form). The name and description attributes are there to make it easier to identify the type of data you're looking at in a section (domain), beyond that though the XML schema is mostly defined by the database column names and the actual values in the export are mostly what are stored in the database (at least with core, no telling what sources third parties may use to include data in this export). Without those two attributes, there's really nothing identifying that you're looking at a user record or a com_contact record or anything like that.

So, if not to be translated strings, why not using system naming ?

Something to get constant variables to be able to manage data from xml programmatically :

<?xml version="1.0"?>
<data-export>
  <domain name="users" description="joomla_users_table_data">
    <item id="398">
      <id>398</id>
      <name>Super User</name>
      <username>admin</username>
      <email>admin@localhost.test</email>
      <block>0</block>
      <sendEmail>1</sendEmail>
      <registerDate>2018-09-19 13:55:15</registerDate>
      <lastvisitDate>2018-09-19 13:56:23</lastvisitDate>
      <activation>0</activation>
      <params/>
      <lastResetTime>0000-00-00 00:00:00</lastResetTime>
      <resetCount>0</resetCount>
      <requireReset>0</requireReset>
    </item>
  </domain>
  <domain name="user_notes" description="joomla_user_notes_data"/>
  <domain name="user_profile" description="joomla_user_profile_data"/>
  <domain name="user_custom_fields" description="joomla_user_custom_fields_data"/>
  <domain name="user_contact" description="joomla_user_contact_data"/>
  <domain name="user_content" description="joomla_user_content_data"/>
  <domain name="user_message" description="joomla_user_message_data"/>
</data-export>

That would work too. When I did this I just went with basic strings to identify things, both as a developer and a potential end user reading this data. Wasn't really looking for a specific naming convention or purpose or anything like that.

That would work too. When I did this I just went with basic strings to identify things, both as a developer and a potential end user reading this data. Wasn't really looking for a specific naming convention or purpose or anything like that.

At first sight, i thought of strings, so of translatable information.

But now, with more insights, i wonder the best way to go... (for sure, not translatable strings, but i wonder if we should let it like this or instead to convert to a convention naming to prevent other persons to think like me to translate those strings... ;-) )

Using a standardized convention like what you've suggested is good enough to me.

Closed in favor of #22253

Should not the xml header use encoding="UTF-8"?

Umm, probably? If you know how to change the PHP DOMDocument class to include this header, this is the relevant code block to change.

i've made a dirty hack here

to
$export = new SimpleXMLElement("<?xml version='1.0' encoding='utf-8'?><data-export />");

if @infograf768 can confirm and if it is not considered too much "hacky" i will do a pr

I looked over the net and your solution does not look as a hack. It is provided by quite a few posters.
I would though intervert the single and double quotes
$export = new SimpleXMLElement('<?xml version="1.0" encoding="utf-8"?><data-export />');

As I still have not set my test site to use Privacy, can't test the above.

i've made a dirty hack here

joomla-cms/administrator/components/com_privacy/helpers/privacy.php

Line 66 in 765c600
$export = new SimpleXMLElement("");

from $export = new SimpleXMLElement("<data-export />");

to
$export = new SimpleXMLElement("<?xml version='1.0' encoding='utf-8'?><data-export />");

if @infograf768 can confirm and if it is not considered too much "hacky" i will do a pr

@alikon It will work like this (commonly used), and tested with Japanese, all is ok now! 👍

Thanks pr coming soon

Il gio 20 set 2018, 13:45 Cyril Rezé notifications@github.com ha scritto:

i've made a dirty hack here

joomla-cms/administrator/components/com_privacy/helpers/privacy.php

joomla-cms/administrator/components/com_privacy/helpers/privacy.php

Line 66 in 765c600

$export = new SimpleXMLElement("<data-export />");

Line 66 in 765c600
http:///joomla/joomla-cms/commit/765c6004f6013c5b6baa7a5126e4c40f1f15e7e5
$export = new SimpleXMLElement("");

from $export = new SimpleXMLElement("");

to
$export = new SimpleXMLElement("");

if @infograf768 https://github.com/infograf768 can confirm and if it is
not considered too much "hacky" i will do a pr

@alikon https://github.com/alikon It will work like this (commonly
used), and tested with Japanese, all is ok now! 👍

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

please test #22285