Skip to content
This repository has been archived by the owner on Dec 31, 2024. It is now read-only.

Translation file placeholder #725

Open
Renato66 opened this issue Oct 9, 2019 · 6 comments
Open

Translation file placeholder #725

Renato66 opened this issue Oct 9, 2019 · 6 comments
Labels
Status: Need More Info Lacks enough info to make progress

Comments

@Renato66
Copy link

Renato66 commented Oct 9, 2019

I have an existing project and im start to implement i18n, but its a little hard to me to see every text that needs to be transformed into $t in my app and we don't have any translations yet making it impossible to the QA team test. Then i made this simple file that put a emoji ✅ in front of every word/phrase based on a 'complete' translation file

// lang/en.js
import ptBr from '../pt-BR' // my  'complete' translation file
export default JSON.parse(JSON.stringify(ptBr).replace(/":"/g, '":"✅ ').replace(/\|/g, '| ✅ '))

this file could be in the docs, or in the files that the plugin changes

@exoego
Copy link
Collaborator

exoego commented Oct 9, 2019

I am sorry but I do noy understand what is your problem and what improvements you expect in vue-i18n.
Could you add more detail?

@Renato66
Copy link
Author

Renato66 commented Oct 9, 2019

when you don't have a translation file in other language, its hard to test if every text is in $t() format
with this you could easily see, where you are missing the $t() because that text wont have a placeholder like ✅ in front of the text

example

here im missing Area Chart Example to be transformed in $t()

@exoego
Copy link
Collaborator

exoego commented Oct 9, 2019

OK, I understood your technique to distinguish translated/non-translated strings visually by adding icons.

BTW, if fallback translation showed, a meesage like "Fall back to translate the keypath 'hello' with 'en-US' locale." will be displayed in the console.

this file could be in the docs, or in the files that the plugin changes

The technique sounds useful for QA, but I think it should not be enabled by default in vue-i18n itself, since such icons should not be displayed in the app in production,.
SGTM to document the technique as TIPS in the docs. Contributions are welcome !!

To distinguish translated/non-translated strings visually (not only log in console), I will propose "FallbackHandler" that allows changing strings in case of fallback, so we may add icon (❌ or 🔥 ) to the fallback locale strings.
Currently, there is MissingHandler that allows changing string only in ase of key missing.
WDYT?

@Renato66
Copy link
Author

Renato66 commented Oct 9, 2019

BTW, if fallback translation showed, a meesage like "Fall back to translate the keypath 'hello' with 'en-US' locale." will be displayed in the console.
I still don't have that file, we are just preparing the soil to receive that translation

To distinguish translated/non-translated strings visually (not only log in console), I will propose "FallbackHandler" that allows changing strings in case of fallback, so we may add icon (❌ or 🔥 ) to the fallback locale strings.

Yah that sounds great ( the 🔥 is better)

The technique sounds useful for QA, but I think it should not be enabled by default in vue-i18n itself, since such icons should not be displayed in the app in production,.
SGTM to document the technique as TIPS in the docs. Contributions are welcome !!

it could have a function in VueI18n constructor that grabs the message object and transforms it

export const i18n = new VueI18n({
  locale: 'pt-BR', // set locale
  fallbackLocale: 'pt-BR',
  showIcons: false, // process.env.NODE_ENV !== 'production' default: false
  messages: {
    'pt-BR': ptBR
  }
})

@kazupon
Copy link
Owner

kazupon commented Oct 27, 2019

Thank you for your feature request!
This feature is very interesting!

However, we need to verify a little more whether this feature breaks other features (e.g. linked messages, Component interpolation, ... etc), due to this feature change locale messages.

export default JSON.parse(JSON.stringify(ptBr).replace(/":"/g, '":"✅ ').replace(/|/g, '| ✅ '))

In particular, this should be handled a little more strictly.

@Renato66
Copy link
Author

@kazupon this feature attends "just" my project, but this pr #732 have some options to toggle and has some tests to make sure that nothing breaks the code =)

@kazupon kazupon added Status: Need More Info Lacks enough info to make progress and removed need more context labels Feb 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Status: Need More Info Lacks enough info to make progress
Projects
None yet
Development

No branches or pull requests

3 participants