-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Export xml Privacy] add language strings for domain #22240
Conversation
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. |
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 |
hmm
so I guess a sprintf has no utility here. |
It is displayed in the xml file of all exported data for one user.
|
Thank you. Understand we get an xml, but how is that xml used ? |
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). |
You may guess I was asking that in relation with translation. The sample code to use the correct language, as @mbabker says, is present in the admin export model
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 |
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) |
plugins/privacy/content/content.php
Outdated
* @var string | ||
* @since 3.9.0 | ||
*/ | ||
protected $lang = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Class member variables do not need to be explicitly initialized with a null value, they default to null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Did the changes
remove default null for $lang
I think mainly to let it case by case as it is in this PR. ;-) |
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 |
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 :
|
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 |
Umm, probably? If you know how to change the PHP |
i've made a dirty hack here
from $export = new SimpleXMLElement("<data-export />");
to 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. |
As I still have not set my test site to use Privacy, can't test the above. |
@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
<https://github.com/joomla/joomla-cms/blob/765c6004f6013c5b6baa7a5126e4c40f1f15e7e5/administrator/components/com_privacy/helpers/privacy.php#L66>
Line 66 in 765c600
<http:///joomla/joomla-cms/commit/765c6004f6013c5b6baa7a5126e4c40f1f15e7e5>
$export = new SimpleXMLElement("");
from $export = new SimpleXMLElement("<data-export />");
to
$export = new SimpleXMLElement("<?xml version='1.0'
encoding='utf-8'?><data-export />");
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 |
…#22253) * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description * [Privacy XML export] standardized convention for domain name and description
Add domain name and description for xml export of privacy elements.