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

i18next integration for Nightscout #4209

Closed
wants to merge 3 commits into from

Conversation

PieterGit
Copy link
Contributor

@PieterGit PieterGit commented Jan 16, 2019

FIRST ATTEMPT, NOT READY, PROOF OF CONCEPT ONLY

@sulkaharo @jpcunningh @MilosKozak @jasoncalabrese

I did a first attempt of integration of i18next for being able to generate translations from source to json files, that can be loaded on runtime. Advantages:

  • This will make the bundle approx ~500kb smaller
  • Only translations that are used are loaded, and they can be cached so that it won't harm the user
  • We can use standard tools in future for maintaining translations
  • Translations are stored in one file per language. Current file is too big for revision tools
  • Less merge conflicts for translations in future.

With npm run translations-scanner the JSON-files per languages in static/tranlsations will be updated based on the source in lib. I started with temporary code to convert the translations from language.js to json files that can be loaded on runtime.

This branch is not ready! I got stuck on the integration. I'm quite busy the next days and hope to have time on sunday to work further on this, so I would like to have your opinion.

Questions:

  • What release to merge? I think this is too late for 0.11.0 and we should postpone it to 0.11.1 or 0.12.x
  • I think the approach for the first release is only to use it for generating the .json files, and do our own mapping at runtime. That means we won't use i18next at runtime for now
  • What's the best way to integration the JSON loading in language.js. I noticed the BASE_URL environment is not used anymore and not available anymore. Should we use a set(newlang, url) so that the caller should provide the url where the language translations are located, or is there a cleaner way.
  • The d3 translations (see https://github.com/d3/d3-geo/blob/master/README.md#projection_translate ) like return 'translate( in lib/client/renderer.js (e.g. in rectTranslate function) causes language translations like:
" + (/*chartWidth + */ padding.left) + ": " + padding.top + ",
  " + (chart().xScale(new Date(d.mills + times.mins(d.duration).msecs)) - chart().xScale(new Date(d.mills)))/2 + ": " + 10 + ",
  " + (padding.left) + ": " + padding.top + ",
  " + (width / 2) +\r\n              ": " + (height / 2) + ",
  " + (xScale2(treatment.mills) + padding.left + 10) + ": " + (padding.top+yInsulinScale(treatment.insulin)) + ",
  " + (xScale2(treatment.mills) + padding.left +10) + ": " + (padding.top+yCarbsScale(treatment.carbs)) + ",
  " + (xScale2(treatment.mills) + padding.left - 2) + ": " + +padding.top + ",
  " + (xScale2(treatment.mills) + padding.left) + ": " + padding.top + ",
  " + arc.svg.centroid(d) + ": "",
  " + chart().xScale(new Date(d.mills)) + ": " + chart().yScale(utils.scaleMgdl(top)) + ",
  " + chart().xScale(new Date(treatment.mills)) + ": " + chart().yScale(client.sbx.scaleEntry(treatment)) + ",
  " + chart().xScale(t.mills) + ": " + chart().yScaleBasals(topOfText) + ",
  " + chartWidth + ": "",
  " + labelArc.centroid(d) + ": "",
  " + padding.left + ": " + (chartHeight + padding.top) + ",

perhaps we should rename non d3 translations to t, or directly start using i18next.t(key, options)

@PieterGit PieterGit mentioned this pull request Jan 16, 2019
@PieterGit
Copy link
Contributor Author

Before merging this stuff, we must also make sure all language PR's (such as #4150 ) are merged to dev first.

@sulkaharo
Copy link
Member

Yay this is awesome! Have you checked how many new keys there are being generated by this & how many keys are missing? Any suggestions on which service to use? I'm assuming we'd integrate some service into the build system to update the files / upload new keys.

@PieterGit PieterGit added this to the 0.12.0 milestone Feb 2, 2019
@PieterGit PieterGit modified the milestones: 0.12.0, 0.12.3, 0.13.0 Jul 24, 2019
@PieterGit
Copy link
Contributor Author

PieterGit commented Jul 24, 2019

This missed the 0.12.x release. Is a good candidate for 0.13.x. @sulkaharo started working on this one a couple of days ago.

Fragment to create separate files in language.js (untested)

  // one time conversion of translations
  const fs = require('fs');
  _.forEach(language.languages, function (l) {
    var translated=[];
    var key='';
    var dict={};
    console.log( 'language: ' + l.code);
       for(var k in language.translations) {
           console.log('lang: '+l.code+ ', key: '+k);
           var o=language.translations[k];
           console.log('translated: '+o);
           dict[k]=o[l.code];
       }
    let data = JSON.stringify(dict);  
    fs.writeFileSync('../static/translations/language-'+l.code+'-resource.json', data);

  } );

@PieterGit PieterGit closed this Sep 3, 2020
@PieterGit PieterGit deleted the 201901_i18next branch September 3, 2020 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants