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

Add auto i18n key prefixing to RouteView::t #2430

Open
johncowen opened this issue Apr 12, 2024 · 0 comments
Open

Add auto i18n key prefixing to RouteView::t #2430

johncowen opened this issue Apr 12, 2024 · 0 comments
Labels
kind/cleanup Cleanup/refactor an existing component/code triage/accepted The issue was reviewed and is complete enough to start working on it

Comments

@johncowen
Copy link
Contributor

johncowen commented Apr 12, 2024

Description

This issue is split off from #1478

Use auto-prefixes (so we don't need to pass long keys to i18n).


Our RouteView component exports a t function for translating i18n keys to human text.

We generally uses a pattern of prefixing every key in a template with module-name.route.route-descrirptor.key for example dataplanes.route.items.page-title.

RouteView knows its own route name, and the route name includes the name of the module, so we could pre configure RouteViews exported t to automatically prefixing that information.

This would mean: t('page-title') would access the dataplanes.route.items.page-title i18n string.


Things to consider before doing this.

  1. Typescript. Our i18n string don't currently auto complete due to our label based DI container injection of 18n strings. This is solvable at some point. But being able to typecheck/autocomplete a call to t to automatically know that you have any keys of dataplanes.route.items... available adds a further complication. Considering we don't currently typecheck our i18n keys I'm not entirely sure given a choice which feature we'd like most - typechecked keys or not having to write the entire path all the time.

  2. In order to add this feature, we would use the RouteView::name attribute. We currently purposefully hardcode in the name of the route taken from the routing config, both string should be exactly equal:


name: 'data-plane-detail-view',

There are two things to consider on this point:

  • Ideally we wouldn't have to hardcode this string exactly the same in two places, and make sure we get it right. I think it would be pretty trivial to add a vite plugin to read the value from our routing config and compile the correct route name onto the RouteView at build time. I did see a fairly official docs link more or less explaining how to do this, but typically can't find it right now.
  • Routing config has a nested structure but our route names don't, well almost don't: Up until now we've use things like dataplane-detail-view and, by convention, prefixed the view name with the module name. But as things get deeper and more nested we are getting things like connection-inbound-summary-overview-view. Furthermore, this view actually would have needed to be dataplane-connection-inbound-summary-overview-view but a connections module was made mainly to avoid these really long names. Ideally route names (and therefore the corresponding *View.vue files) would automatically "name themselves" depending on the nested structure. i.e. if I create a routing config for an 'overview view' in 'dataplane > connections > inbounds > summary' it is automatically called dataplane-connection-inbound-summary-overview-view and then statically added to RouteView::name at build time. This would happen automatically and the only thing I would do as an engineer is put the config in the correct nesting level and name it overview-view, the rest would be added by the build.

Note the above consideration are just that - considerations, they aren't necessarily required to finish this task, but the outcome of considerations will dictate how much effort is required here.

Lastly my gut feeling is that this issue/task would be nice, but its by no means a must have feature.

@johncowen johncowen added triage/pending This issue will be looked at on the next triage meeting kind/feature New feature labels Apr 12, 2024
@johncowen johncowen added kind/cleanup Cleanup/refactor an existing component/code and removed kind/feature New feature labels Apr 12, 2024
@jakubdyszkiewicz jakubdyszkiewicz added triage/accepted The issue was reviewed and is complete enough to start working on it and removed triage/pending This issue will be looked at on the next triage meeting labels Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cleanup Cleanup/refactor an existing component/code triage/accepted The issue was reviewed and is complete enough to start working on it
Projects
None yet
Development

No branches or pull requests

2 participants