Enhance the wording when downloading a document

[audez]

Context

Currently, after clicking the "Download" button in a document, the displayed options are:

• "Download full document and history"
• "Remove document history (can significantly reduce file size)"
• "Remove all data but keep the structure to use as a template"

Many users do not understand the 2nd and 3rd options, or they are afraid to choose them as they think it will delete the history or the data from the document itself.

Proposed solution

A French user suggested the following phrasing to make the options clearer:

• "Download document and history"
• "Download document without history (can significantly reduce file size)"
• "Download document structure only (no data, for template use)"

Has this been tested?

• 👍 yes, I added tests to the test suite
• 💭 no, because this PR is a draft and still needs work
• [x ] 🙅 no, because this is not relevant here
• 🙋 no, because I need help

Tested locally.

Screenshots / Screencasts

[manuhabitela]

👋

Seeing this, I'm wondering: when updating the English version of already-existing translation strings, should we change the original string used as a key? Or should we rather keep the original text as key in the code, but change only the new text value in the english locales file?

If we change the key, I guess it means English text appears for every locale where translation strings have not been updated. Not that great.

If we don't change the key, it means other locales have some dated translations that don't match new wording. And I guess it's difficult to be aware of changes that should be made. Not that great either. But at least it doesn't put back to english some parts of the app.

Or maybe weblate does some magic stuff to handle some of this?

[dsagal]

I like the new wording, thank you!

As for @manuhabitela's question, at least in theory, it would be possible to update the text in code, and update all translations to use the new keys but the existing translations. Separately, it should be possible to check the "Needs editing" checkbox for each of them in Weblate. That way we get to keep existing translations, which is better than reverting to English, and translators get visibility into what needs to be done. I just don't know of a way to do these steps except manually for each language.

[audez]

@dsagal you're welcome!
I don't mind doing that manually (with a good podcast :), could you just please confirm that the steps would be:

• in the file MakeCopyMenu.ts, i put the new string (already done)
• in en.client.json, i put the new string key and new string (already done)
• in all the locales files *.client.json, i replace the old EN string with the new string (and preserve the old translation)
• in Weblate, I check the "Needs editing" for each language

I could take this opportunity to improve this other string that seems unclear to users: in Acces Rules, "Type a message..." placeholder (after clicking the "Message" icon). We could replace it by one of those:
- "Message displayed to the user if the action is restricted." or
- "Specify the error message for restricted access." or
- "Warning message if the user lacks permission."

What do you think?

[dsagal]

Yes, those are the steps! As for improving to the placeholder in Access Rules, also yes, that would be great. I discussed the message internally and here's the edit we suggest:
"Type message to display when this rule blocks an action…"

[audez]

Perfect! Before I dive, do you think of any other string that could be improved?

[nataliemisasi]

@audez The string in Access Rules under Special Rules is another that could be made more clear.

Currently reads: Allow editors to edit structure (e.g. modify and delete tables, columns, layouts), and to write formulas, which give access to all data regardless of read restrictions.

Update to: Allow editors to edit structure (e.g., modify and delete tables, columns, and layouts) and write formulas. Formulas can access all data, regardless of read restrictions.

Thanks for your help with these improvements!

[audez]

Hi @nataliemisasi, is it intentional that if we give the "S" rule to an editor, and we set a "read-only" rule on top of the "S" rule, they won't be able to edit existing data columns (that's ok), but they will be able to edit existing formula columns?

I'm asking because a French user would like to allow editors to change the layout (create views, mask or move columns), but not the structure of the tables, so the only way he found was to apply these 2 rules - but by doing this editors can edit the formulas (and can't revert their changes).

If it was intentional, why would you think about this wording, so we cover every case:
"Allow editors to edit structure (e.g., modify and delete tables, columns, and layouts), edit all formulas (regardless of edit restrictions) and write new formulas (that can access all data, regardless of read restrictions)."
?

[nataliemisasi]

@audez correct - the 'S' permission specifically allows you to edit formulas. So even if a column is not editable based on table-level permissions, an editor could still modify the formula. It is a bit confusing so agree a little note about that would be useful.

"Allow editors to edit structure (e.g., modify and delete tables, columns, and layouts), edit all formulas (regardless of edit restrictions) and write new formulas (that can access all data, regardless of read restrictions)."

Suggestion: Allow editors to edit structure (e.g., modify and delete tables, columns, and layouts) and write formulas. Regardless of the permissions set at the table and column level, formulas can still be edited and can access all data.

[dsagal]

@nataliemisasi's suggested wording makes sense. Maybe a slight edit like this?

Allow editors to edit structure (e.g., modify and delete tables, columns, and layouts) and write formulas. Note that all formulas can be edited and can access all data regardless of the permissions set at the table and column level.

As for the reason, it's not so much intentional as just that it's the more basic functionality. Editing structure includes many different kinds of things you can edit. We only have one bit to control it because we haven't added more. It would definitely make sense to have separate controls for editing table/column structure, editing formulas, and editing layouts. For formulas, paying attention to the edit rights in a table may make sense too, but there we would need options as well -- sometimes it is fine to give someone permission to edit formulas (e.g. to analyze data), but the data itself should be protected from changes.