Generator-jhipster: Metrics page with Angular+noi18n: translation-not-found

[pascalgrimaud]

Overview of the issue

Following the switch to micrometer, the metrics page is not correctly displayed for Angular application without translation noi18n. There are some translation-not-found.

No issue for React, it works well.

Motivation for or Use Case

Reproduce the error

• Generate an application with Angular, noi18n
• Start the application
• Go into metrics page

Related issues

Suggest a Fix

JHipster Version(s)

Current master at

• 2469b83df - (HEAD -> master, upstream/master) Merge pull request #8985 from pervezcse/8790-issue-fix (il y a 6 heures)

Welcome to the JHipster Information Sub-Generator

JHipster Version(s)

[email protected] /home/pgrimaud/tmp/21-ngx-noi18n
└── [email protected] 

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**

.yo-rc.json file

{
    "generator-jhipster": {
        "promptValues": {
            "packageName": "io.github.pascalgrimaud"
        },
        "jhipsterVersion": "5.7.2",
        "applicationType": "monolith",
        "baseName": "jhipster",
        "packageName": "io.github.pascalgrimaud",
        "packageFolder": "io/github/pascalgrimaud",
        "serverPort": "8080",
        "authenticationType": "jwt",
        "cacheProvider": "ehcache",
        "enableHibernateCache": true,
        "websocket": false,
        "databaseType": "sql",
        "devDatabaseType": "h2Disk",
        "prodDatabaseType": "mysql",
        "searchEngine": false,
        "messageBroker": false,
        "serviceDiscoveryType": false,
        "buildTool": "maven",
        "enableSwaggerCodegen": false,
        "jwtSecretKey": "bXktc2VjcmV0LXRva2VuLXRvLWNoYW5nZS1pbi1wcm9kdWN0aW9uLWFuZC10by1rZWVwLWluLWEtc2VjdXJlLXBsYWNl",
        "clientFramework": "angularX",
        "useSass": true,
        "clientPackageManager": "npm",
        "testFrameworks": [],
        "jhiPrefix": "jhi",
        "entitySuffix": "",
        "dtoSuffix": "DTO",
        "otherModules": [],
        "enableTranslation": false
    }
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

Environment and Tools

openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-0ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

git version 2.20.1

node: v10.14.1

npm: 6.4.1

yeoman: 2.0.5

yarn: 1.12.3

Docker version 18.03.0-ce, build 0520e24

docker-compose version 1.21.2, build a133471

INFO! Congratulations, JHipster execution is complete!

• [x] Checking this box is mandatory (this is just to show you read everything)

[wmarques]

@pascalgrimaud seems that we have jhiTranslate directives in the lib, even if the app doesn't use translations...

[wmarques]

It's going to be quite hard to manage, because the ng-jhipster lib always provides translation tools, it "doesn't care" about the jhipster app config.
What we do to manage the app without translation is when we copy the HTML template, we strip the jhiTranslate directives from the HTML. But this doesn't work in the ng-jhipster HTML templates because they are already packaged in the lib.

So for me there are two options:

1. In the jhiTranslate directive, check if i18n is enabled before doing translation
2. Always use translation and remove the translation question in the generator (for Angular). For me, you always want to at least manage your labels in an external file and not hard code them in your HTML.

I would personally go for the first option.

@jhipster/developers WDYT ?

[atomfrede]

I would go for removing no-translations because I also think no one should have their texts in the template files.

[DanielFran]

I also believe that we should always have translation.
So go for removing no-translations

[wmarques]

@atomfrede agree with you, but in can add complexity for user who wants some really simple app for a POC for instance... Well, for now, I did the fixes in order to keep this working :)

[deepu105]

I originally coded the noI18n option and the use case is still valid for
me, not everyone will use translation and in real use cases especially
within companies translation is never used and in such scenarios, it just
adds bloat and a little performance loss for no gain so I would like to
keep the option. We can easily pass if i18n is enabled or not to lib and
skip translating accordingly. I think we already pass the value

Thanks & Regards,
Deepu

On Tue, Jan 15, 2019 at 5:03 PM William Marques [e-mail]
wrote:

@atomfrede https://github.com/atomfrede agree with you, but in can add
complexity for user who wants some really simple app for a POC for
instance... Well, for now, I did the fixes in order to keep this working :)

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/9048#issuecomment-454446597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF--TY2K9G_k4D5_SjHUNcoAxoXTKks5vDfvNgaJpZM4Z8hw9
.

[wmarques]

@deepu105 Yep it's in the ConfigService so that's good, I did the according changes in the lib, should be good once the lib is released.