search

ReadAlongs / Studio-Web-archived

ReadAlong Studio Web Interface
Other
2 stars 2 forks source link

Add i18n and French translation #27

Closed dhdaines closed 1 year ago

dhdaines commented 1 year ago

This is based on Eric's branch because it has more stuff to translate. I don't know the proper Git incantation that will be required to make it merge to main properly, leaving that to you ;-)

joanise commented 1 year ago

Nice! That was quick. Yeah, I can sort out the merging. Can you review my PR first? I'll want to do them one at a time to keep it clean.

joanise commented 1 year ago

OK, this is pretty cool. I'm surprised to see the code use the English messages all over, does that mean the text we put in the .html templates is generating a hash that is a key to the messages.*.json databases? So, from here on, if I want to change the text in the GUI, I need to modify not the template, but both json files, right?

Also, is there a good GUI tool to edit the message database? I recall one when I did translations for Aidan, so I assume the answer will be yes, and I really want to use something spreadsheet like to modify the messages, not just edit the raw json files manually...

joanise commented 1 year ago

Urgh, I just created a conflict by modifying my plain text example. I guess we need to merge this localization PR asap and do all future work on top of it, otherwise each change will introduce conflicts...

roedoejet commented 1 year ago

Yea, I am curious about this too. I typically use ngx-translate which does runtime translation instead of angular's built-in compile-time translation library. I think there are pros and cons to both. I'm curious if we can get a more descriptive editing interface too. I've used BabelEdit and POEditor in the past

joanise commented 1 year ago

Next question: how hard is it to add a French/English button to toggle the language live?

roedoejet commented 1 year ago

Next question: how hard is it to add a French/English button to toggle the language live?

So if you're thinking a toggle button that changes the language in the same way the WordWeaver one does, I'm not sure that's possible this way. https://github.com/ngx-translate/core let's you change the language without reloading the page, but for this to work, I think we'd have to have /en/ and /fr/ addresses for the site, so it wouldn't live-toggle they would actually be different sites. In any case, this is great David! But maybe we should have a conversation about how to implement this before merging. I'm usually a fan of ngx-translate and runtime translation instead of the built-in compile time Angular translation, but I'm open to having my mind changed

dhdaines commented 1 year ago

OK, this is pretty cool. I'm surprised to see the code use the English messages all over, does that mean the text we put in the .html templates is generating a hash that is a key to the messages.*.json databases?

Hi! No, the code won't use the English messages from messages.json. It is just there for reference. Look in angular.json to see how the messages files are configured:

      "i18n": {
        "sourceLocale": "en",
        "locales": {
          "fr": "src/i18n/messages.fr.json"
        }
      },
dhdaines commented 1 year ago

Yea, I am curious about this too. I typically use ngx-translate which does runtime translation instead of angular's built-in compile-time translation library. I think there are pros and cons to both. I'm curious if we can get a more descriptive editing interface too. I've used BabelEdit and POEditor in the past

I gave up very quickly on POEditor, its interface is really not at all obvious and I couldn't figure out what value it was adding for just me creating translations on my own.

This is one reason I chose to use the JSON format instead of XLIFF, because it's quite easy to just copy the messages.json and change all of the strings. The other reason is that the JSON format supports inline markup in the messages which is abstracted away with things like {$START_LINK}. This didn't seem to work in any obvious fashion in XLIFF.

dhdaines commented 1 year ago

But maybe we should have a conversation about how to implement this before merging. I'm usually a fan of ngx-translate and runtime translation instead of the built-in compile time Angular translation, but I'm open to having my mind changed

Yeah, I decided to use the built-in compile time translation because it looks like ngx-translate is no longer maintained, but on the other hand I think ngx-translate has much better documentation, and I see the appeal of runtime translation - it seems wasteful to create multiple builds of the site, the overhead of loading the messages is negligible, and then you will just get the language your browser requests automatically.

Actually I may have just convinced myself to redo this with ngx-translate...

dhdaines commented 1 year ago

OK, this is pretty cool. I'm surprised to see the code use the English messages all over, does that mean the text we put in the .html templates is generating a hash that is a key to the messages.*.json databases?

Hi! No, the code won't use the English messages from messages.json. It is just there for reference.

Oops, I think I misunderstood your question. The answer is yes. The English messages are the reference language, and the message ID used in the messages.*.json are generated from them using some sort of hashing.

joanise commented 1 year ago

OK, this is pretty cool. I'm surprised to see the code use the English messages all over, does that mean the text we put in the .html templates is generating a hash that is a key to the messages.*.json databases?

Hi! No, the code won't use the English messages from messages.json. It is just there for reference.

Oops, I think I misunderstood your question. The answer is yes. The English messages are the reference language, and the message ID used in the messages.*.json are generated from them using some sort of hashing.

OK, so there's a potential problem, which I just tested: if I change a piece of text in the code, the hash is changed. The updated English is displayed fine, which is good, but the French then suddenly display the English text for that message, which I guess is what happens when it doesn't find the new hash as a key in the json. That makes perfect sense for a partially translated web site, but it means updating a piece of English text requires 1) changing the text, 2) finding out what the new hash is (I'd like to know how to do that), 3) changing the translation in each .json file.

Now, I see you have i18n="Header for upload box" on the various elements that have text. I wonder why that's not the key into the strings database instead of a hash of the English text...

joanise commented 1 year ago

Man, sorry for the million questions... I'm working on polishing the text―I figure even if we change how we do i18n, we'll still keep this text, so I'm not wasting my time―and I noticed another potential issue: on the Privacy and data sovereignty policy dialog, I want to translate "Ok" as "D'accord", but if there was another "Ok" button elsewhere, that one might be better translated as "Valider". Does this tool allow use to have the same message translated in two different context-sensitive way?

joanise commented 1 year ago

Hey, sweet, when I merged my own PR in, GitHub automatically switched your target branch from my PR branch to main. Nice feature! That means it's OK to do a PR on top of another PR, GitHub adjusts automatically when the first one is merged. I like that. (I'll still have to rebase, since I created a conflict when I updated my PR branch, but that's an orthogonal issue.)

dhdaines commented 1 year ago

Now, I see you have i18n="Header for upload box" on the various elements that have text. I wonder why that's not the key into the strings database instead of a hash of the English text...

Because Angular's i18n is stupid, that's why :) it's possible to define custom identifiers which are stable, but I didn't figure out how to do it yet.

dhdaines commented 1 year ago

Man, sorry for the million questions... I'm working on polishing the text―I figure even if we change how we do i18n, we'll still keep this text, so I'm not wasting my time―and I noticed another potential issue: on the Privacy and data sovereignty policy dialog, I want to translate "Ok" as "D'accord", but if there was another "Ok" button elsewhere, that one might be better translated as "Valider". Does this tool allow use to have the same message translated in two different context-sensitive way?

The standard translation for an "OK" button is "Valider" which has always seemed strange to me, but it is what it is :)

joanise commented 1 year ago

Man, sorry for the million questions... I'm working on polishing the text―I figure even if we change how we do i18n, we'll still keep this text, so I'm not wasting my time―and I noticed another potential issue: on the Privacy and data sovereignty policy dialog, I want to translate "Ok" as "D'accord", but if there was another "Ok" button elsewhere, that one might be better translated as "Valider". Does this tool allow use to have the same message translated in two different context-sensitive way?

The standard translation for an "OK" button is "Valider" which has always seemed strange to me, but it is what it is :)

Valider is fine when you're saying Ok, I've filled this form, or Ok, launch this thing with options I picked. I don't like it either, though. But here we're more like asking the user to agree to the terms. And in fact, I think we should change the English to "I agree" instead of "Ok".

dhdaines commented 1 year ago

I agree!

On Thu, Dec 15, 2022 at 10:28 AM Eric Joanis @.***> wrote:

Man, sorry for the million questions... I'm working on polishing the text―I figure even if we change how we do i18n, we'll still keep this text, so I'm not wasting my time―and I noticed another potential issue: on the Privacy and data sovereignty policy dialog, I want to translate "Ok" as "D'accord", but if there was another "Ok" button elsewhere, that one might be better translated as "Valider". Does this tool allow use to have the same message translated in two different context-sensitive way?

The standard translation for an "OK" button is "Valider" which has always seemed strange to me, but it is what it is :)

Valider is fine when you're saying Ok, I've filled this form, or Ok, launch this thing with options I picked. I don't like it either, though. But here we're more like asking the user to agree to the terms. And in fact, I think we should change the English to "I agree" instead of "Ok".

— Reply to this email directly, view it on GitHub https://github.com/ReadAlongs/Studio-Web/pull/27#issuecomment-1353268725, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLYUGV4LJ7ZPZT7SCMC2DWNM2IFANCNFSM6AAAAAAS55Z2D4 . You are receiving this because you authored the thread.Message ID: @.***>

dhdaines commented 1 year ago

Dev dependencies are actually build dependencies, they'll be used for building all the targets. Terminology mismatch between Python and Node...

On Thu, Dec 15, 2022 at 10:30 AM Eric Joanis @.***> wrote:

@.**** commented on this pull request.

In package.json https://github.com/ReadAlongs/Studio-Web/pull/27#discussion_r1049783797:

@@ -43,6 +44,7 @@ @./build-angular": "^14.2.0", @./cli": "^14.2.0", @.***/compiler-cli": "^14.2.0",

  • @.***/localize": "^14.2.12",

OK, but the prod build will need it too, right? If it's in dev dependencies, the prod build won't have it and it'll fail, won't it? Or am I misunderstanding how node builds stuff?

— Reply to this email directly, view it on GitHub https://github.com/ReadAlongs/Studio-Web/pull/27#discussion_r1049783797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLYUFFFURCKMS233UUJZ3WNM2P7ANCNFSM6AAAAAAS55Z2D4 . You are receiving this because you authored the thread.Message ID: @.***>

joanise commented 1 year ago

Dev dependencies are actually build dependencies, they'll be used for building all the targets. Terminology mismatch between Python and Node...

OK, thanks for that clarification. That's good to know.

joanise commented 1 year ago

@dhdaines @roedoejet Looking for a consensus now - do we stick with this approach to i18n and l10n or do we switch to something else? I need to fix the conflict in the branch, but if we're going to start again differently I might not bother.

joanise commented 1 year ago

As far as I'm concerned, this is a fine approach. Having URL/fr and URL/en be two separate single-page app is fine, as long as we make it clear to users that switching language implies a reload.

dhdaines commented 1 year ago

As far as I'm concerned, this is a fine approach. Having URL/fr and URL/en be two separate single-page app is fine, as long as we make it clear to users that switching language implies a reload.

I'm fine with it too, I think switching langugaes on the fly is of limited usefulness, and just looking at the documentation for ngx-translate, it is much much much more intrusive than the built-in i18n, which turns out to be pretty good, actually.

joanise commented 1 year ago

I've just merged main into this branch and resolved the conflict with the text modifications in my previous PR.

I've just noticed an issue: the tour is all broken. If you click on "Montrez-moi!" the tour gets displayed and the various dialogs pop up, but the text in the tour bubbles is all blank, including the buttons. I'm still investigating, but I wanted to mention it now in case you know what causes that.

joanise commented 1 year ago

I've just noticed an issue: the tour is all broken. If you click on "Montrez-moi!" the tour gets displayed and the various dialogs pop up, but the text in the tour bubbles is all blank, including the buttons. I'm still investigating, but I wanted to mention it now in case you know what causes that.

Never mind that, the problem just fixed itself. Must have been a random glitch. I have no idea what I changed to make it go away, what I did was modify shepherd.steps.ts and save it and then it worked. Undid the modifications, it still works. Must have been a random bad state in ng serve...