search

Eurydia / project-amethyst

A record tracking application for very specific requirements.
GNU General Public License v3.0
0 stars 0 forks source link

Phrase and wording standardization #8

Closed Eurydia closed 1 month ago

Eurydia commented 2 months ago

Button labels, search field placeholders, page headings, table headings should have the consistent wording and description.

Eurydia commented 2 months ago

Originally, the goal was to create a locale object and collect a list of common words and phrases in it. This way, I can swap similar phrases without having to go through every components and pages.

The issue was that some words and phrases are unique, one such example is the tool tip title for the sort-supported table which has "ascending" and "descending." These two words are unique and they are not seen anywhere else in the application.

Another issue is the naming convention for the named phrases, take LOCALE.driverAddButtonLabel and LOCALE.buttonLabelAddDriver, these two refer to the same phrase and describe the label on a button, which on click, will take the user to the driver registration form.

Yet another issue the dynamic phrase which contains dynamic data. Normally, the locale object has the type Record<string,string>, but to accommodate for the dynamic data, it has to be transformed into Record<string, string | (dt: string) => string> type.

Eurydia commented 1 month ago

The idea of locale object has proven to be useful as reusable error messages in route loaders. However, trying to extend it to user-facing UI elements has been unsuccessful.

The most obvious example as to why applying the locale object to UI elements does not work is the DriverInputDriverSelect component.

The component itself contains two localization words, one to display "no option" and the other appears in the placeholder of the input field to show the user that they can search for a specific driver via their name, surname, and contact information.

The point is, even though it is possible to life the placeholder up as a slotProp, it is unreasonable to do so, since it is strongly linked to the filtering logic within the component itself.