linagora / angular-translate-quality Goto Github PK

Add verifications related to the syntax.
Example: in English, colons do not accept a space before while they need one in French.

• Go the the webhooks tab in the repository settings page
• Click ‘Add webhook'
• Set the right URL
• Select ‘Send me everything’ option, keep all other defaults
• Click ‘Add webhook'

Quotes are missing around the key.

Sometimes, the filter may be incomplete.

Example: {{'COMMON_DELETE'}} while it should be {{'COMMON_DELETE' | translate}}

Currently, the following JSon file is considered as valid.

{
     "key1": "value 1",
     "key2": "value 2"
     "key3": "value 3"
}

A comma is missing and this is not detected by the library.

Alt attributes should all be verified.

Unit tests only use absolute file paths.
With relative locations, it does not work.

I see no standard which imposes UPPERCASE keys, a flag to avoid this check would be nice to have.

var res = qual.validate({
  loc_i18n: './src/i18n/**/',
  loc_html: './src/app/**/'
});

... does not display error messages.
Temporary workaround:

var res = qual.validate({
  loc_i18n: './src/i18n/**/',
  loc_html: './src/app/**/',
  cb: console.log
});

var res = qual.validate() works as expected.
There is something wrong when we override options.

See this PR (#28) for details.
Tests for alphabetical order does not work the same way everywhere.

That's not the case!
See https://travis-ci.org/linagora/angular-translate-quality/builds/226516806

The build is green while a unit test failed.

Warnings should be printed but should not fail.

The following HTML snippet...

<th ng-show="showAppColumn"><span ng-class="findClass('application')" ng-click="setCriteria('application')">{{'COMMON_APPLICATION' | translate}}</span></th>

... results in the following error...

An unknown i18n key is referenced in ./src/app/commands/html/_commands_history_directive.html. Key name: application')">{{'COMMON_APPLICATION

Adding a space before {{ solves the error.
We should upgrade the search pattern to ignore HTML mark-ups.

The job will be launched manually.
CI is already handled by Travis.

It does not make sense to have white space characters in values.

The translate argument is not recognised and the line marked as missing translation

Such warnings with this option should result in an error.

The following afaik should be a valid json angular-trnslate file

{
  "accept-privacy": {
    "title": "Accept Privacy Policy",
    "accept": "Accept",
    "acceptTitle": "Accept Policy",
    "text": "By clicking accept, you will be redirected to the application registration page from where you will be able to login again."
  }
}

but the regexp /^(\t)?"([^"]+)": "([^"]*)",?/ does not match.

• Multiple indent characters (a better default indent pattern should be \s*)
• Characters { and } not matched in any case

See https://www.npmjs.com/package/gulp-coveralls

Hi!

I have been reviewing the code of an Angular-JS application and I found some text I had hard-coded in my controller. Something like...

rClient.updateApplicationBindings($routeParams.appName, prefix, appNames).then(function() {
  $scope.status.push({
    ok: true,
    msg: 'Bindings for prefix "' + prefix + '" were successfully saved.'
  });

}, function(response) {
  $scope.status.push({
    ok: false,
    msg: 'An error occurred while saving the bindings for prefix "' + prefix + '".'
  });
});

What was correct before I use Angular-Translate now leads to incomplete internationalization. I thought we could use Angular-Translate-Quality to detect such an oversight. However, how to not throw warnings for all the strings (such as module names)?

We could use what was used in Java: add comments with $non-nls-1$.
Example:

(function() {
  'use strict';   // $non-nls-1$

  angular
  .module('roboconf.application-bindings')  // $non-nls-1$
  .controller('ApplicationBindingsController', applicationBindingsController); // $non-nls-1$

Such comments can be removed automatically by tools when compacting the code. The real issue would be with linters that limit the size of a line. Or we could decide to not detect these cases and expect people to review their code. Indeed, these comments make the code ugly (or uglier than usual).

What do you think?

The callback can be used as an example to verify the key is used in a JS file.

Forbidden patterns were introduced, among other things, to verify typography rules in translations. However, there are cases where such rules are counter-productive. That's the case for date patterns, where people usually use :.

Forbidden patterns should be actionable or ignorable for some translations.
We should add (another) option for that.