Reword "Browse or Add from files"

[purplespider]

Can I propose rewording the "Browse" and "Add from files" links on the Upload field?

I just feel that the current wording is a bit ambiguous, especially to less "savvy" CMS users. "Browse" could mean "Browse the files in the CMS" or "Browse files on your computer", and "Add from files" could mean "Add from files in the CMS" or "Add from files on your computer".

How about:
"Upload or Add from 'Files'"

Open to other suggestions. Ideally, it should be:

• Short and succinct
• Clear as to if it's locating files on the user's computer or already uploaded files
• Shouldn't mention "Computer", as we could be on an iPad / smartphone.

The "Upload" label is used for this exact action within the Files area and modal, so using it here would also improve consistency.

I don't like the "From the CMS" wording that SS3 used, as the files don't really belong to the CMS.

While capitalising the 'F' on "Files" may slightly more associate it with the CMS's "Files" area, I don't think it's quite enough.

[maxime-rainville]

I agree with @purplespider. The first time I got confronted with a choice between Browse and Add from file, I was confused.

[DorsetDigital]

"Upload" and "Add from Files" work for me. It can be argued that the latter is still slightly ambiguous, but when given as the alternative to 'Upload' I think it becomes much more obvious.

[mlewis-everley]

"Upload" and "Add Existing"?

[jonom]

I agree this is confusing for the user. I clicked the wrong link the first few times using SS4 and I'm supposed to know my way around :)

I like: Upload new or Choose existing

Choose is maybe slightly more appropriate than Add because you're not adding a new file to the asset store.

[jonom]

A year later I still click the wrong option most times when I use the CMS 😄😭

Happy to submit a PR for this but wondering about the process. The strings in question are mapped to AssetAdmin.ADD_FILES and AssetAdmin.BROWSE. Is it appropriate to use the same i18n keys but change the values, since the intended meaning hasn't changed?

In the mean time here is a hack for anyone wanting to replace these labels. You can load something like this in to the CMS via SilverStripe\Admin\LeftAndMain:extra_requirements_javascript config property. No doubt there's a better way to do this but it works okay.

var overrideUploadLabels = function () {
  if (
    typeof (ss) !== 'undefined'
    && typeof (ss.i18n) !== 'undefined'
    && typeof (ss.i18n.lang) !== 'undefined'
    && typeof (ss.i18n.lang.en) !== 'undefined'
    && typeof (ss.i18n.lang.en['AssetAdmin.ADD_FILES']) !== 'undefined'
  ) {
    ss.i18n.addDictionary('en', {
      "AssetAdmin.ADD_FILES": "Choose existing",
      "AssetAdmin.BROWSE": "Upload new"
    });
  } else {
    // Try again later
    window.setTimeout(overrideUploadLabels, 2000);
  }
};
overrideUploadLabels();

Edited for a slightly better hack

[maxime-rainville]

If the meaning of the words actually change, I think we need to add a new translation string.

You can get more information about how to update translation strings here https://docs.silverstripe.org/en/4/contributing/translations/

[jonom]

I don't think the intended meaning would be changing. I imagine that in some (many?) of the translations the labels are already less ambiguous which is all we are trying to achieve here, so I think it would probably be best to use the same keys. Another consideration is that if we introduce new keys it might take a while for new translations to trickle in, and in the mean time non-english speakers would see english labels there.

In terms of how to do this, I looked at the translation docs but it doesn't look like it's been updated to account for React components yet. I looked at the module on transifex and there don't seem to be any EN translations, so If I understand right we should only need to update the source lang file (which I presume is this one?) as well as fallback text for BROWSE and ADD_FILES. Then Transifex can pull in the updated source, and we can then pull back updated translation json files from Transifex for each locale, then we can build them in to js files (but I don't know how that part works). Is that about right?

Gotta say, I love React but I miss how easy these things were to do before all these build tools got involved!

Side note: it would be nice if .js lang files were generated by the standard /dev/build process on a per project basis, and took in to account user lang files. It used to be easy to override translatable strings with your own preference but I don't see an easy or reliable way to do that now (hence that ugly code snippet in a previous comment). This would allow non-english developers to quickly ship translations in their projects too, while they wait for them to be accepted on Transifex and eventually rolled in to a module release.

[robbieaverill]

@jonom it might be worth raising your feedback on a framework issue. It's easy to override YAML translations in user code, but you're right - it's much more difficult with JavaScript translation files, and as you also said, they aren't automatically collected like PHP and .ss templates are with i18nTextCollector. With SilverStripe moving more into a JavaScript space we do need to investigate these areas a but further, for sure.

By the way, the file you referenced is correct for the source translation file. You need to add the entries manually at this stage, and they are automatically pushed and pulled via Transifex during releases.

When adjusting translations, please don't remove any or change the nature of existing ones (like @maxime-rainville was saying, I think). For example, "My green car" being changed to "My colourful cars" - a parallel equivalent of this might make sense as a UI change in SilverStripe but it would invalidate non-English translations for the original. We can add new ones easily, however, and this will be backwards compatible for when the (single versioned) translations are pulled into each separate minor release branch of our modules.

[robbieaverill]

Will be available in SilverStripe 4.5, thanks @jonom