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.

Sign up for GitHub

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

Jump to bottom

Recommendation: Avoid duplicate translation keys #191

Closed
jniles opened this issue Mar 11, 2016 · 3 comments
Closed

Recommendation: Avoid duplicate translation keys #191

jniles opened this issue Mar 11, 2016 · 3 comments
Assignees
@DedrickEnc
Labels
Best Practice

Comments

@jniles
Copy link
Contributor

jniles commented Mar 11, 2016

Our translation files always seem to be expanding. I've noticed lots of additions in PRs coming into the repository. You can also see for yourself, just run this command (linux):

less client/src/i18n/fr.json | grep "UPDATE_SUCCES"

You should see the following output:

   "UPDATE_SUCCESS_MESSAGE" : "Mise à jour avec succès !"
   "UPDATE_SUCCESS_MESSAGE" : "Mise à jour avec succès !"
    "UPDATE_SUCCESS"         : "Mis à jour une caisse avec succès."
   "UPDATE_SUCCES"        : "Mis à jour avec succès"
   "UPDATE_SUCCES"        : "Mis à jour avec succès"
   "UPDATE_SUCCES"     : "Mis à jour avec succès"
   "UPDATE_SUCCES"  : "Mis à jour avec succès"
   "UPDATE_SUCCES"  : "Mise à jour avec succès"
  "UPDATE_SUCCESS"    : "Mise a jour du depot avec succès"
   "UPDATE_SUCCES"  : "Mis à jour avec succès"
   "UPDATE_SUCCESS"     : "Mis à jour avec succès"
   "UPDATE_SUCCES"            : "Mis à jour avec succès"
   "UPDATE_SUCCES"  : "Mis à jour avec succès"
   "UPDATE_SUCCES"   : "Mis à jour avec succès",
   "UPDATE_SUCCES"  : "Mis à jour avec succès",
   "UPDATE_SUCCES"  : "Mis à jour avec succès"
      "UPDATE_SUCCESS" : "Item modifié!"
   "UPDATE_SUCCES"  : "Mis à jour avec succès"
   "UPDATE_SUCCESS" : "Patient modifier avec succès",
   "UPDATE_SUCCES"  : "Mis à jour avec succès",
   "UPDATE_SUCCESS" : "Fait un mis a jour avec success.",
   "UPDATE_SUCCES"  : "Mis à jour avec succès"
   "UPDATE_SUCCES"   : "Mis à jour avec succès",
   "UPDATE_SUCCES"   : "Mis à jour avec succès",
   "UPDATE_SUCCES"  : "Mis à jour avec succès",
   "UPDATE_SUCCES"          : "Mis à jour avec succès"
   "UPDATE_SUCCESS" : "Mise à jour avec succès"
   "UPDATE_SUCCES"       : "Mise à jour avec succès"
   "UPDATE_SUCCESS" : "Mise à jour avec succès"

That is a lot of repeated phrases that are hard to maintain, wasted space when shipped to the client, difficult to find and edit, and overall just poor programming practice.

Proposal
Someone should create form translation keys that can be used by any module to convey generic messages such as "created", "updated", "errored", etc. It would look like this:

<span class="text-success">{{ 'FORM.UPDATED' | translate }}</span>
<span class="text-success">{{ 'FORM.CREATED' | translate }}</span>
<span class="text-danger">{{ 'FORM.ERRORED' | translate }}</span>
<span class="text-warning">{{ 'FORM.DELETED' | translate }}</span>

With just this simply consolidation, we can probably eliminate > 100 lines from our translation files.
@DedrickEnc , would you review this proposal and assign it to someone if you think it is a good idea?
@DedrickEnc
Copy link
Contributor

We planed to design the translation file entirely, do you think it is not
worth to wait until we will finish financiary module development?
If not, I will do it!
Le 11 mars 2016 15:08, "Jonathan Niles" notifications@github.com a écrit :

Our translation files always seem to be expanding. I've noticed lots of
additions in PRs coming into the repository. You can also see for yourself,
just run this command (linux):

less client/src/i18n/fr.json | grep "UPDATE_SUCCES"

You should see the following output:

"UPDATE_SUCCESS_MESSAGE" : "Mise à jour avec succès !"
"UPDATE_SUCCESS_MESSAGE" : "Mise à jour avec succès !"
"UPDATE_SUCCESS" : "Mis à jour une caisse avec succès."
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mise à jour avec succès"
"UPDATE_SUCCESS" : "Mise a jour du depot avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCESS" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès",
"UPDATE_SUCCES" : "Mis à jour avec succès",
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCESS" : "Item modifié!"
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCESS" : "Patient modifier avec succès",
"UPDATE_SUCCES" : "Mis à jour avec succès",
"UPDATE_SUCCESS" : "Fait un mis a jour avec success.",
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCES" : "Mis à jour avec succès",
"UPDATE_SUCCES" : "Mis à jour avec succès",
"UPDATE_SUCCES" : "Mis à jour avec succès",
"UPDATE_SUCCES" : "Mis à jour avec succès"
"UPDATE_SUCCESS" : "Mise à jour avec succès"
"UPDATE_SUCCES" : "Mise à jour avec succès"
"UPDATE_SUCCESS" : "Mise à jour avec succès"

That is a lot of repeated phrases that are hard to maintain, wasted space
when shipped to the client, difficult to find and edit, and overall just
poor programming practice.

Proposal
Someone should create form translation keys that can be used by any module
to convey generic messages such as "created", "updated", "errored", etc. It
would look like this:

{{ 'FORM.UPDATED' | translate }}
{{ 'FORM.CREATED' | translate }}
{{ 'FORM.ERRORED' | translate }}
{{ 'FORM.DELETED' | translate }}

With just this simply consolidation, we can probably eliminate > 100 lines
from our translation files.

@DedrickEnc https://github.com/DedrickEnc , would you review this
proposal and assign it to someone if you think it is a good idea?

—
Reply to this email directly or view it on GitHub
#191.

@jniles
Copy link
Contributor Author

jniles commented Mar 11, 2016

If we fix this sooner, the less work we will have to do later. It is similar to building components first, then using them in the module.

I say we do it sooner rather than later!

@DedrickEnc DedrickEnc self-assigned this Mar 13, 2016
@jniles
Copy link
Contributor Author

jniles commented Apr 13, 2016

This was closed via #197 and #283.

@jniles jniles closed this as completed Apr 13, 2016
jniles referenced this issue in jniles/bhima Jan 24, 2017
fix(vouchers): implement clear() on form
7de3257 
This commit cleans up the form simple voucher form's worst hacks and
replaces them with _slightly_ cleaner code.  It also implements a
clear() button.

Closes #191.
DedrickEnc pushed a commit to DedrickEnc/bhima-2.X that referenced this issue Jan 25, 2017
@jniles @sfount
feat(voucher): Patient Invoice Debt Transfer (IMA-WorldHealth#186)
7d08f3c 
* feat(voucher): Patient Invoice Debt Transfer

This commit implements a payment of a patient's debts via the Simple
Voucher module.  The debts are written off towards an account - in the
present use case, against an account belonging to a debtor group.

* fix(vouchers): implement clear() on form

This commit cleans up the form simple voucher form's worst hacks and
replaces them with _slightly_ cleaner code.  It also implements a
clear() button.

Closes IMA-WorldHealth#191.

* fix(currency): improve translation/rendering

This commit improves the bhCurrencyInput's translation and rendering by
making sure the currency is always rendered in uppercase and using the
more efficient translate directive instead of the translate filter.

* refactor(vouchers): SimpleVoucher use VoucherForm

This commit refactors the Simple Voucher module to use the VoucherForm.
The VoucherForm brings with it numerous advantages:
 1. Better error detection and handling
 2. Built-in caching.
 3. Cleaner separation of view/model

This makes the SimpleVoucher module much easier to extend and operate
in the future.

* fix(vouchers): fix e2e test

This commit fixes a case-sensitive issue in the simple vouchers form.

* fix(voucher): fix general bugs

This commit fixes the simple vouchers to have more maintainable code,
closes some tags, and makes sure that the appropriate values are
triggered when the scan barcode modal closes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DedrickEnc DedrickEnc

Labels
Best Practice
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jniles @DedrickEnc