phrase / vue-i18n-phrase-in-context-editor

Adapter for using Phrase In-Context Editor with vue-i18n
https://phrase.github.io/vue-i18n-phrase-in-context-editor/
MIT License
5 stars 2 forks source link

Unable to dismiss sign in dialog #7

Closed henrikbernstrom closed 3 years ago

henrikbernstrom commented 4 years ago

Using vue-i18n-phrase-in-context-editor@1.0.2 and when having the sign in dialog appearing, it seems impossible to get rid of it, if you decide not to use the translation tool. Would be nice to have a cancel option and to not being forced to do a work-around myself.

My setup options:

  Vue.prototype.$phraseInContextEditor = new VueI18nPhraseInContextEditor(i18n, {
    phraseEnabled: false,
    projectId: phraseProjectId,
    autoLowercase: false,
    autoLogin: {
      perform: false,
    },
  });
FRSgit commented 4 years ago

Hey @henrikbernstrom! Sorry that it took so long to respond - we actually had few internal talks about this. Unfortunately, we won't add functionality to dismiss the login dialog.

The flow we currently do support is to have a separate environment just for handling the translations and to enable the Phrase ICE on the environment variables level.

Actually, enabling the ICE can be done in sort-of-dynamic fashion (the script for the ICE is being loaded only for the first time the phraseEnabled proparty is set to `true), but there is no option for unloading.

So I see the two options for you here:

  1. Create an "enable phrase" button somewhere in you demo environment and hide it once the Phrase ICE is enabled.
  2. You could try to hack hiding of already enabled Phrase ICE:
    window.phrase.ui.$target.hide();

    But it's not something we officially support at this moment.

henrikbernstrom commented 4 years ago

Ok, just got to say that I don't really understand the chosen strategy. The sign-in dialog is a modal. Why force an environment (which is not your environment) to have the Phrase ICE active if the user would like to chose not to?

Regarding your suggestions, point 1 is exactly what we've done. Works really nice and prior to putting the phraseEnabled property to true the fist time, we will not be forced to have a signed in Phrase user. So, why is it a thing for you to letting the sign-in dialog being dismissable?

Yes, I can hack the solution to put my own kind of X-button on top of your modal, to have it closed but.. Naah, I just don't get this. :D

FRSgit commented 4 years ago

Sorry that you feel this way, I totally get you! The most problematic thing is that we are in the middle of migrating of the old, legacy, jquery & bootstrap@3-based codebase to simpler, vanilla js&boootstrap@4 form. We just don't want to mess with the existing code by adding new features now.

I'll raise your concern on our board, but because we are pretty limited on the frontend resources I would say it will take time to have it 🐌 Basically, first the migration to the new bootstrap & jquery-free environment must be done and that unfortunately also is a bit tricky topic. The code for the base In-Context Editor plugin is really tangled in some places and it really take some times to figure it out.

Hopefully, some day I would be able to just write here "okay, it's done!", but we are not there yet :< That's why I have proposed the other solutions - I just know, that doing it on your side would be better, at least for now.

I hope you understand our situation and if you have any other question/problem I'm more than happy to help! 🚀

I'm leaving this issue open, so I can write any follow-up when I have the decision about what to do with your feature proposal (or, in the best case when I have this feature already implemented) 🕐

henrikbernstrom commented 4 years ago

Ah! I see! Sorry for breaking apart in my last message. It all makes more sense now.

I’ll fix it on our side. ☺️

HENRIK BERNSTRÖM

+46 708-423566 henrik.bernstrom@gmail.com Pålsbovägen 2 S-302 74 Halmstad

19 aug. 2020 kl. 16:39 skrev Jakub Freisler notifications@github.com:

 Sorry that you feel this way, I totally get you! The most problematic thing is that we are in the middle of migrating of the old, legacy, jquery & bootstrap@3-based codebase to simpler, vanilla js&boootstrap@4 form. We just don't want to mess with the existing code by adding new features now.

I'll raise your concern on our board, but because we are pretty limited on the frontend resources I would say it will take time to have it 🐌 Basically, first the migration to the new bootstrap & jquery-free environment must be done and that unfortunately also is a bit tricky topic. The code for the base In-Context Editor plugin is really tangled in some places and it really take some times to figure it out.

Hopefully, some day I would be able to just write here "okay, it's done!", but we are not there yet :< That's why I have proposed the other solutions - I just know, that doing it on your side would be better, at least for now.

I hope you understand our situation and if you have any other question/problem I'm more than happy to help! 🚀

I'm leaving this issue open, so I can write any follow-up when I have the decision about what to do with your feature proposal (or, in the best case when I have this feature already implemented) 🕐

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

FRSgit commented 3 years ago

@henrikbernstrom Hey, just to let you know - I'm closing this issue, because the In-Context Editor's login modal now has the close button! There is no option to reopen the ICE after it has been closed though. For this, the user would need to reload the page. But because still, the use case for ICE is running it on the separate environment - I'd say it's fine enough, right?

We also have refactored the ICE, so it doesn't use jQuery anymore! Because of that, the overall size (bundle & assets) was reduced by 55%! 🎉 Lots of things have been changed under the hood, so if you encounter any problems with the new ICE please create an issue on github or write to us at: support@phrase.com

Cheers 🥂