JS Proxy Integration overwriting anchors

Crowdin Issues
1

I have an odd issue with JS Proxy Integration of overwriting anchors (only in one situation).

I have a website published to github pages, which uses javascript (https://app.lizardbyte.dev/js/navbar.js) to create the navbar based on the content of the page. For each section in the page a new navbar entry is created.

Near the bottom of the javascript you will find

navbar_link.href = `#${sections[i].id}`

Which should be #Home for example.

Locally, this works as intended. If I navigate to my page at https://app.lizardbyte.dev or https://app.lizardbyte.dev/index.html then it does not work and there is a prefix added to the href. I also have the site duplicated in en and es-ES directories. Navigating to https://app.lizardbyte.dev/en/ works correctly, as well as https://app.lizardbyte.dev/en/index.html

Why do I need it to be the original href, you may ask… Because it dynamically highlights the link in the navbar as you scroll. When the href is modified this doesn’t work. This is done via Scrollspy so it much be the anchor that I specified.

I believe that the integration is overwriting the href without checking if it’s an anchor. I’m happy to share any other details to help diagnose this.

1 Like
2

Probably would be better to use In Context in this case. It binds your website with pseudo-language strings in Crowdin, so you can hide some strings, like anchors. JSproxy should scan then whole page regardless of anchor or not.

1 Like
3

Try another method for language detect type, it’s in application settings, for example query parameter

Screenshot from 2022-10-25 14-52-02
Screenshot from 2022-10-25 14-52-02883×354 34.3 KB

1 Like
4

Originally I used query parameter. This has the same issue. Switching to Subdirectory at least allows Scrollspy (part of Bootstrap) to work on the /en or /es-ES pages.

The anchor strings are not translated. They are changed from #Home to https://app.lizardbyte.dev/index.html#Home

That is to say <a class="nav-link fw-bold menu-list" href="#Home">Home</a> is becoming <a class="nav-link fw-bold menu-list" href="https://app.lizardbyte.dev/index.html#Home" i18next-orgval-0="Home" localized="" dir="ltr">Home</a>

Scrollspy requires that the href target is an id of a DOM object.

I can’t find any valid reason why this integration would change an anchor, other than it may be an oversight in the integration.

To add to this, the href is overwritten whether using the default language or alternate, and the href value is the same for both situations.

I did scan through the javascript of the integration (https://proxy-translator.app.crowdin.net/assets/proxy-translator.js) but it was not obvious to me what part would need to change.

1 Like
5

I have also attempted to move the navbar.js below the crowdin javascript; however no change in this issue. Didn’t think that would really work since the crowdin integration does read strings generated by javascript after the page is initially loaded, but it was worth a try.

1 Like
6

Very interesting case. I’ll probably even test it a little, because never seen that before. You use this one, right?

Probably it would be better to record some type of video or maybe some test project/website that demonstrates this behavior and share it with Crowdin’s manager or responsible team. In case it’s something from their side, I’m sure they’ll be able to fix it.

2 Likes
7

Hello, @ReenigneArcher hope you’re doing just great.

I’ve checked the JS Proxy status from my side, and it works, as usual, nothing unexpected, which means this is a default behavior of this tool. I agree with @VoldemarSamrani - please record a screencast with voice comments that describe and explain in detail what you’re experiencing right now, and what this experience should be. I’d like to share it with our development team. You can provide it here, or in direct conversation to make things more private.

1 Like
8

I use v5.0, but essentially, yes. Scrollspy · Bootstrap v5.0

@Dima I can try to record something. It’s pretty obvious though if you go to my website. https://app.lizardbyte.dev/ (https://app.lizardbyte.dev/) then scroll down and you will see the highlighting of the elements in the navbar does not work. Then go to https://app.lizardbyte.dev/en/ (https://app.lizardbyte.dev/en/) and you will see they do highlight as you scroll.

Disabling the crowdin javascript on the first link, and the highlighting will again work as it should.

Bootstrap’s Scrollspy requires the hrefs to begin with # and point directly to an id of an element in the page.

Edit: Screen capture (sorry, no mic) https://youtu.be/PWkYkp8hB0E

1 Like
9

I discovered that if I change the baseUrl to some random address, the hrefs are not changed (makes sense)… this is the case if languageDetectType is subdirectory.

    window.proxyTranslator.init({
        baseUrl: "https://app.blah.dev",
        distributionBaseUrl: "https://distributions.crowdin.net",
        ...
        languageDetectType: "subdirectory",
    });

But that obviously causes issues with navigating to other pages.

Anyway, hopefully someone can take a look at this. I cannot think of any valid reason why an href that starts with # should be modified since that is meant to go to a location in the already loaded page.

1 Like
10

Proxy is designed to work with slashes + language, like /en /es /fr and so one. To me it seems like default tool behavio.

2 Likes
11

I’ll investigate the details you’ve provided from my side.

2 Likes
12

Hello @ReenigneArcher :slightly_smiling_face:

Discussed your case with the team. We can start investigating the possibility of adding an improvement to the JS Proxy script, and there are 2 very first ideas on the matter:

  1. Add a callback, as a result, you’ll manage by yourself the callbacks response/situation
  2. Allow you to add specific parameters to these anchors classes so as result they would be recognized in another way and not overwritten

Please choose the best one for you. In case you have any other ideas - please feel free to share them.

2 Likes
13

@Dima

That’s great news! I think option 2 would be preferable. Possibly could just add a class such as crowdin-ignore-href or something along those lines.

Thanks!

1 Like
14

Well noted, passed to the tech team :slightly_smiling_face:

2 Likes
15

Hello, @ReenigneArcher we’ve fixed hashtags. Also, now in Site Settings, you can set ignore ID + ignore CSS classes

2 Likes
16

Thank you for the update

3 Likes