alphagov / govuk-frontend

GOV.UK Frontend contains the code you need to start building a user interface for government platforms and services.
https://frontend.design-system.service.gov.uk/
MIT License
1.18k stars 325 forks source link

Character Count 'count message' cannot be customised or translated #1681

Closed 36degrees closed 2 years ago

36degrees commented 4 years ago

The Character Count contains hardcoded English strings in both the template:

https://github.com/alphagov/govuk-frontend/blob/12f0d6cbe1a5650b8bd61d5ade9e502684f2a167/src/govuk/components/character-count/template.njk#L29

… and the JavaScript:

https://github.com/alphagov/govuk-frontend/blob/12f0d6cbe1a5650b8bd61d5ade9e502684f2a167/src/govuk/components/character-count/character-count.js#L147-L159

This means this text cannot be customised or translated (for example into Welsh) without forking the JavaScript for the component.

matthewmascord commented 4 years ago

Have there been any developments on this issue recently? We need to be able to supply a version of this component with the message translated to Welsh and this is not currently possible.

nataliecarey commented 4 years ago

The HMRC approach is to have language as a parameter which can be set to en or cy (for example https://design.tax.service.gov.uk/hmrc-design-patterns/open-links-in-a-new-window-or-tab/)

Being able to set the text directly would be another solution but it de-centralises the default text in Welsh.

If you need Welsh content provided I'm sure HMRC can help.

36degrees commented 4 years ago

Hi Matthew,

Unfortunately at the minute we don't have a solution for localisation / internationalisation.

For now, we suggest that you copy the Javascript for this component into your service's codebase and make the adjustments required for the service you’re working on.

nataliecarey commented 4 years ago

If we raise a PR to allow this content to be set would that be appropriate? That feels consistent with the other components.

Edit for clarity: I'm talking about the user specifying whatever content they want to replace phrases like "You can enter up to" - in our use-case we'd put in the Welsh translation

hannalaakso commented 4 years ago

@natcarey We're going to need to consider internalisation/localisation as part of a wider piece of work to ensure the approach will work for all Javascript components including more complex ones in the future. This is related to https://github.com/alphagov/govuk-frontend/issues/1708 and https://github.com/alphagov/govuk-frontend/issues/1722.

So for now we won't be able to accept a contribution on this but thanks so much for offering to work on it, it's much appreciated 🙌 If you wanted to leave any thoughts on either of the above linked issues please feel free to do so.

nataliecarey commented 4 years ago

Thanks, I'll take a look at those other issues.

RickyWelch commented 4 years ago

Application Platform Services also have the need for this to be translatable for applications such as the SA-Filing years where a Welsh equivalent of the app is a requirement.

simonneb commented 4 years ago

The solution will need to be able to accurately count characters and not bytes.

The GDS Notify team recently updated their internal character counting to more accurately reflect the number of non English characters, so might be worth chatting with @quis ?

36degrees commented 4 years ago

@simonneb there's a separate issue for that – #1104. Would you be able to add a comment there instead?

mgladdish commented 4 years ago

Another +1 for this. Can we get this fixed without having to wait for an entire internationalisation design review? Even just exposing a js variable with a stringformat for the message would be an improvement - then at least our apps can override the text without having to fork the entire project. It would be hacky, yes, but still better than the current situation.

36degrees commented 4 years ago

Even just exposing a js variable with a stringformat for the message would be an improvement - then at least our apps can override the text without having to fork the entire project.

We do not currently have a way to pass configuration variables into a component, other than through data attributes.

Can you expand on what you mean by a stringformat? Do you have an example of what that might look like?

mgladdish commented 4 years ago

Actually data attributes should be fine.

If we can pass a template in as an attribute, and the js can evaluate that instead of building its own hard-coded string, then we're good.

E.g. we could pass "you have {{max}} characters remaining" as an attribute, and the js knows to pass a max arg to the template. Or even just do it with template string literals if you don't have the nunjucks engine in scope.

girishkamat commented 3 years ago

Hello, any progress on this issue? If not, do you recommend copying the CharacterCount code into application codebase and make the the required changes?

hannalaakso commented 3 years ago

@girishkamat We’re currently preparing for this work but cannot unfortunately give a timeline.

For now, we suggest that you copy the Javascript for this component into your service’s codebase and make the adjustments required for the service you’re working on.

Thanks for your patience.

domoscargin commented 2 years ago

Hi all,

This has been completed as part of our work on localisation and should be available in an upcoming release.

Thanks for your feedback (and patience!)