Skip to content
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

Tests for translations #608

Open
patrickjahns opened this issue Jan 31, 2019 · 14 comments
Open

Tests for translations #608

patrickjahns opened this issue Jan 31, 2019 · 14 comments

Comments

@patrickjahns
Copy link
Contributor

It would be great to have acceptance tests for apps that show/display strings for translations.

Trying to catch when translations are not / no-longer working like in owncloud/files_antivirus#291

@phil-davis
Copy link
Contributor

Note: core has a test that switches language to Russian and checks.

It will be "easy enough" to do similar checks in apps, at least of a few sample strings which demonstrate that the translation infrastructure is working. But to cover every place that has a string to be translated is not "easy" and not maintainable - translators can update the translation at any moment.

@phil-davis
Copy link
Contributor

Is the text of API responses translated?
(probably the text of "success" will be "OK" and not get translated! But the text of failures like "group already exists" or... might be translated).

We could change the system language to Deutsch and check some API responses to see that they are translated. The current translation of those is unlikely to change, so the tests will not get broken.

@DeepDiver1975
Copy link
Member

All Web Apis respect the accept-language Header. The given language Code ist used for strings which are returned

@DeepDiver1975
Copy link
Member

@jasson99
Copy link

jasson99 commented Mar 3, 2020

I changed the system language to 'default_language' => 'de' . Then I created a new user namely deutschUser and added it to the admin group. When the deutschUser now logs in, the language in the web UI is Deutsch. But, when the deutschUser makes an API request to create an already existing user, the message is still "User already exists".

@phil-davis
Copy link
Contributor

@jasson99 try sending the Accept-Language header with the curl command. Set it to * (all languages) and that might make the API choose the system language, rather than English. Then also try sending a specific language code.

See the link in comment #608 (comment)

@phil-davis
Copy link
Contributor

@DeepDiver1975 or anyone. Are occ commands supposed to have any translation capability?
e.g. translate to the system language, for input prompts and/or output success/error messages?

@DeepDiver1975
Copy link
Member

@DeepDiver1975 or anyone. Are occ commands supposed to have any translation capability?

no - plain english

@phil-davis
Copy link
Contributor

Hmmm - exceptions out of DAV do not seem to be translated, e.g. https://github.com/owncloud/core/blob/master/apps/dav/lib/Connector/Sabre/Directory.php#L262

throw new SabreNotFound('File with name ' . $path . ' could not be located');
curl http://172.17.0.1:8080/remote.php/webdav/notAvailable.txt -u deutchUser:deutchUser -X GET -H "Accept-Language:*" -H "Content-Type: text/plain"
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>
  <s:message>File with name notAvailable.txt could not be located</s:message>
</d:error>

I wonder how we find an example WebDAV call that will provide an "interesting" response that gets translated.

@DeepDiver1975
Copy link
Member

It is highly possible that not all messages are translated 🤷‍♂️

Let me try to find a working example ...

@DeepDiver1975
Copy link
Member

$ curl -H 'Accept-Language: de' -uadmin "http://localhost:8080/ocs/v2.php/apps/files_sharing/api/v1/shares/1"
Enter host password for user 'admin':
<?xml version="1.0"?>
<ocs>
 <meta>
  <status>failure</status>
  <statuscode>404</statuscode>
  <message>Fehlerhafte Freigabe-ID, Freigabe existiert nicht</message>
  <totalitems></totalitems>
  <itemsperpage></itemsperpage>
 </meta>
 <data/>
</ocs>

@phil-davis
Copy link
Contributor

Now we have some testing infrastructure for running test scenarios in different languages.

The next question is "how widely do we test"?

  • various API endpoints
  • various UI elements
  • ???

If we want to know that every string that is required to be translated actually is translated, then there would be 1000 test cases. (that is, if we want some test to fail if any one of the $l->t() type of translation calls gets removed or does not work).

Otherwise, what subset of test cases do we cover?

@phil-davis
Copy link
Contributor

I removed @Talank as assignee, marked as done in the current QA project, and put the issue back into the QA backlog. We need to discuss the comment #608 (comment) before doing more work.

@dpakach
Copy link
Contributor

dpakach commented May 19, 2021

Currently, there are few places where we have tests for translations but the coverage is very low

  1. API tests for translations checking the response messages in the API requests
    https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiTranslation/translation.feature
  2. WebUI tests for translation that check proper translation is used when the language setting is changed

https://github.com/owncloud/core/blob/master/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature

What we can do more on this

  1. The translation function that is used for translating the strings can be checked with linting or other code analyzers. We can search for such tools or methods how that can be done.
  2. Check how we can test the entire page for translation. We can look for a way to do this more efficiently.
  3. We can maybe try to use the translation files (eg. https://github.com/owncloud/core/blob/master/lib/l10n/de.json) and check if the UI matches with these translations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants