Turn aupterms into a config setting

[peter-]

I suggest removing aupterms as a translatable string and adding a configuration variable for it. I'd imagine a dict as shown below would suffice to allow specifying AUP terms even in multiple languages (as raised by Étienne on the dev list):

$config['site_aup'] = [
  'en' => 'Your AUP',
  'en_AU' => 'Your AUP, mate',
  'fr' => 'Votre AUP ici',
];

Reasoning (as also provided in the email thread referenced above) is that AUP terms are site-specific and unlikely to be applicable to all sites merely sharing a language.

Making that into a config setting avoids every site having to override software-/POEditor-provided "translations" (using the config/language/ mechanism provided) with their local AUP terms, even if all other translations are acceptable for the language(s) they intend to enable/support.

N.B.: about_text shares some aspects of the issue I raise about aupterms above, though arguably its value could remain the same for all instances of the software -- provided incorrect/misleading translations such as "Impressum" in the de-lang are fixed. (An "Impressum" identifies the party legally responsible for the content/service, you wouldn't want to conflate giving credit to the FileSender project with making the FileSender project legally resonsible for every instance of the software.)

[WebSpider]

Your suggestion to add translation options into the configuration file is an interesting one, and I understand which problem it aims to solve. It also opens up the issue of us having to start maintaining translations in different parts of FileSender, which I'm not too keen about.

Another solution that I've seen used is make the site_aup/aupterms a separate file/page/HTML link, that is either served by the FileSender webserver, or is at a different location completely, such as a Wiki external to FileSender, but controlled by the same administrators. Would that solve the problem?

[peter-]

Your suggestion to add translation options into the configuration file is an interesting one, and I understand which problem it aims to solve. It also opens up the issue of us having to start maintaining translations in different parts of FileSender, which I'm not too keen about.

ACK, though it wouldn't be you/the project having to maintain anything here: The defaulted configuration variable in includes/ConfigDefaults.php could be the empty string (or PHP null or whatever's the convention here) so simply nothing to manage.
Same as with site_name and site_url today.

Another solution that I've seen used is make the site_aup/aupterms a separate file/page/HTML link, that is either served by the FileSender webserver, or is at a different location completely, such as a Wiki external to FileSender, but controlled by the same administrators. Would that solve the problem?

Sure, not using FileSender's build-in methods to present some basic content to people using the software is always a possibilty. Do these external-to-the-FileSender-software resources have the same branding and design applied as FileSender (so people recognise those are actually about the FileSender site they were just potentially sent away from)? Do those resources have the same i18n support (and based on the same technical selection criteria and supported locale identifiers) so that the content will show up in the same language as the FileSender UI was shown in when they clicked on one of those links that took them elsewhere?
While I guess that's all achievable in principle using external tools -- no matter whether hosted on the same server as FileSender or elsewhere -- and so fully outside of this project's code and responsiblity, it'd also be a lot more work for deployers to get the same i18n features and consistent look on external resources compared to just using the software as it was provided so far.

In case you meant deployers could create their own custom template files that tie into FileSender's API (in order to easily get the same design and i18n features for their custom content) and put those within FileSender's installation somewhere I think this is even more complex than the continued (mis-)use of the translation feature/s for site-local configurations. But maybe with sufficient documentation (if that doesn't exist already) there might be a small use-case to use the FileSender API as a CMS-for-the-poor. (No idea whether you're actually suggesting that -- I certainly am not! I'm just trying to make sense of the suggested alternatives and what consequences those will have for deployers.)

[WebSpider]

ACK, though it wouldn't be you/the project having to maintain anything here: The defaulted configuration variable in includes/ConfigDefaults.php could be the empty string (or PHP null or whatever's the convention here) so simply nothing to manage. Same as with site_name and site_url today.

Ah, yes, that makes sense. Given your example, I thought you were wanting to provide a default for each seperate language.

I'm just trying to make sense of the suggested alternatives and what consequences those will have for deployers.

Actually, I was just making a small list of what I've seen out there as solutions to this problem. Each has upsides and downsides, obviously. Let's work out what we thing works best here.

[monkeyiq]

Certainly some of the translation terms are used more as a way to allow a site to customize what is shown in parts of the UI. Is the motivation for putting these terms into config so that a single installation can serve two or more distinct FileSender instances each with their own acceptable terms?

[peter-]

Certainly some of the translation terms are used more as a way to allow a site to customize what is shown in parts of the UI. Is the motivation for putting these terms into config so that a single installation can serve two or more distinct FileSender instances each with their own acceptable terms?

Not at all. I thought this to be simple and obvious:

• Strings that can be shared by multiple instances using the same language (possibly run by different deployers/orgs) should be translation terms, such as delete_my_account. Wording commonly does not need to change across instances using the same language.
• Strings that are site-specific / cannot be shared by multiple instances using the same language should be configuration variables, such as site_name. It makes no sense to manage these as translation terms where you can only have one shared value per language.

If language-wide vs. site-specific is not the guiding principle when to put things into translation terms and when to put them into configuration variables such as site_foo then I don't know what else could be?

The fact that aupterms belongs to the latter category (site-speific) seems obvious considering the software does not even provide actual content for this term:

filesender/language/en_AU/aupterms.html.php

Line 10 in d4bda80

AuP Terms and conditions...

If the project believed that there could be one universally applicable AUP wording per language they would have provided it as a translation term. But there's nothing usable there, meaning each site is fully expected to provide their own content, making it site-specific, not language specific. Ergo a configuration variable, not a translation term.

(Sorry for having to use so many words to state what is very obvious from the way the software itself is handling this case.)

As to why deployers need to be able to set this for multiple languages, Étienne has already provided that argument: One instance of the software can clearly support multiple languages, consequently it would be desirable to have your AUP available in those same languages.

[monkeyiq]

I see the language-wide vs. site-specific distinction.

Another good suggestion for terms which might be in the translation system but may also be overridden in a site-specific way is email header and footers. The translation can supply a "Thank you for using FileSender." type footer or nothing as a default and a specific site might like to have a site-specific version of this mentioning something that a deployment feels should be in each email sent out. Though this is also a case where a blank default can make sense and the override is to allow a site to set policy. For AUP for a specific language there is likely nothing that can be set on poeditor that makes sense to everybody. It should be changed by a site if they enable the acceptance of an AUP by users.

I was asking about the config variable vs translation term difference to work out the implementation details around if a site was wanting to serve different AUP depending on the user or group who was logging in. That may not be possible currently using the config/language method unless a site specific prefix could be set for a session at login.

[monkeyiq]

After more consideration it seems maybe the issue is the existence of terms like service_aup_body_version_1 in the translation system which are themselves more of a place holder for a site to set with their specific terms. Such terms can not really have a good text for any language in the default poeditor and distribution of FileSender. They exist only to allow a deployment to set their value of they are wanting to show AUP terms.

This being the base the motivation to use $config['service_aup_body_version_1'] = ...; is to eradicate these terms from the poeditor system.

[peter-]

After more consideration it seems maybe the issue is the existence of terms like service_aup_body_version_1 in the translation system which are themselves more of a place holder for a site to set with their specific terms. Such terms can not really have a good text for any language in the default poeditor and distribution of FileSender. They exist only to allow a deployment to set their value of they are wanting to show AUP terms.

This being the base the motivation to use $config['service_aup_body_version_1'] = ...; is to eradicate these terms from the poeditor system.

Yeah, seems like that's another example where "site configuration" is currently expected to be done by "translation override" instead, which seems needlessly complicated (when it could be done with configuration in the existing config.php file) once it becomes clear that those parameters are site-specific cannot have sensible values in POEditor.

[peter-]

I.e., anything in POEditor that's more of a "placeholder" isn't a translatable term.

[WebSpider]

Currently we use POEditor for e-mail template management as well. Typically, this is one of the things people will want to tune to their local install, so that would be more of a "placeholder".

I agree with the general suggestion in this issue, but it does touch FileSender in quite a few locations.
Contributions would be welcome here.