You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2020/06/22 17:17:13 UTC

[GitHub] [incubator-superset] ktmud commented on pull request #10129: chore: fix add datasource help string

ktmud commented on pull request #10129:
URL: https://github.com/apache/incubator-superset/pull/10129#issuecomment-647660031


   @etr2460 Ideally you would want unique translation keys even if not for performance, because proper translation needs context---For example, the text "Next" could mean either "next page" or "next item", but in languages like Chinese, "next" has to be followed by a noun/classifier, so we can't just use one translation for all places the text appears.
   
   You'd also want your keys to be something meaningful and namespaced, otherwise it'd be very hard to communicate with translators or debug.
   
   In large international website, there's normally a i18n service and developers need to mark translation keys for the client side on the backend API by API. Then the client side uses translations returned along side the regular data response.
   
   For smaller i18n projects, it's OK to use the process you described. I actually had an SPA many many years ago and did something similar: https://www.npmjs.com/package/yaml-i18n-brunch
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org