Received. I'm reviewing your proposal.

Thank you @Maryann-Onyinye .

Weekly report

1. Overview of Tasks Completed:

• Task 1: Passing message to execute functions, changing icons and removing unnecessary headings
• Task 2: Refactor SignItCoreContent for browser compatibility & modal init fix
• Task 3: Introduce internationalization inside SignItVideosGallery.js
• Task 4: Updating _locales messages as per browser.i18n API

2. Key Accomplishments:

• Accomplishment 1: I guess executing functions by passing messages can count as accomplishment , as this was pretty challenging. Earlier even when the

codebase worked in firefox it used _backgroundPage API as namespace and fetched the contents of background page like object key-value pairs. But since we cant do so in chrome , I figured passing messages from popup/content scripts to excute functions in service worker would just work fine. I have expanded on this under te challenges faced.

• Accomplishment 2: Internationalizing SignItVideosGallery.js isn't that big of accomplishment, but counts as development. Importing banana module inside other files head been a challenge for quite a while. While I was not able import it either but I made a function which mimicks the behaviour of what banana.i18n did, thereby restoring the functionality inside the above mentioned file. Now when the user changes UI language , the language inside videos gallery changes as well.

3. Challenges Faced:

• Challenge : Extension to the above mentioned accomplishment., well the reason I count this as challenging as there were other methods as well. Like:-
  • Using a shared common-functions file - Technically it is the ideal approach , but it wasn't working as expected. It threw errors regarding the functions not being found.
  • Storing functions inside local storage: While we cant do that , it is technically possible by making it a string (like an actual string and not using JSON.stringify())and storing its arguments inside an array , then rebuilding it by parsing it and passing the items inside the functions. Seems a bit bizarre and makes for unnecessary code but if it were to happen , functions would be available wherever needed as they are in local storage.

• Solution: I ultimately ended up with using messages to execute functions seperately inside service_worker/backgrounf-script.

4. Learnings and Skills Gained:

• Learning : Got to understand more about how service workers work behind the scenes, how we can use local storage to make things more accessible betwen files when working with extension development and a little about internationalization.

5. Feedback and Support Needed:

Feedback/Support : I appreciate the feedback I've been getting on my approach! To ensure a smooth merge, I was hoping we could have a closer look at the code changes themselves. A more in-depth code review would be appreciated.

6. Goals for Next Week:

Goal 1: Restore settings tab fully functional.
Goal 2: Work on hindi i18n messages
Goal 3: Work on how Popup UI's language changes differently as compared to modal's language and video gallery's language change. It has something to do with local storage , I'll look into it.
Goal 4: Refactor toggleColoredWords function such that it works in Chrome as well.
Goal 5: Convert timers like setTimeout to alarms as part of Migrating to service worker checklist.

Weekly Report (3 June - 9 June)

1. Overview of Tasks Completed:

• Task 1: Fixing POST Request and Refactoring Related Functionality. Fixing this also achieved one of my goals i.e., to make toggleColoredWords function work in chrome.
• Task 2: Code enhancements

While these were technically not the goals I mentioned earlier , they still count as development.

2. Key Accomplishments:

• Accomplishment 1: Making the video files and records' POST request work in extension environment can be considered as an achivement. Since many other components relied on it to work.
• Accomplishment 2: Recognizing the incompatibilty of .ogv file in Chrome environment. Turns out that due to security issues this format was going to be removed and many people had already transitioned to .webm format. Issue to migrate to a different format has been raised. See here

3. Challenges Faced:

• Challenge : Overcoming the API endpoint issue can be considered a challenge. Earlier we used jQuery to send post requests but since we can no longer do that in chrome extension environment , using native fetch API remained the only way. The problem is it responded with HTTP Status code 405 : Method Not Allowed when sent with fetch API. This had been a persistent issue for quite a while now.

• Solution: Instead of sending payload data as part of req.body, I tried sending it (necessary queries and data format) in the form of query parameters and it worked! I changed the URL accordingly. I'm aware that the code still looks like a get request but I will work on refactoring that in the next week.

4. Learnings and Skills Gained:

• Learning : Learnt that endpoints need to be thoroughly tested in every way possible.

5. Goals for Next Week:

I would continue on my previous week's goals as I delved into some other issues this week as mentioned earier which were equally produtive if not better.

Weekly Report (10 June - 16 June)

1. Overview of Tasks Completed:

• Task : fix : i18n. Used message passing to perform i18n tasks directly inside sw/background-script. While this made the function async in nature it also fixed a lot of issues like instant refresh of both Popup and Modal UI upon changing to desired language and also removed the use of unnecessary multiple i18n systems , be it self-made(in Chromium) or the use of old banana.i18n library(in Firefox). Now we solely rely on the old libraray for all the browsers ,so we can say that it is a centralized system. As compared to what we did earlier it is less verbose as well. Also helped close the issue #84

2. Key Accomplishments:

• Accomplishment : Harmonized i18n system such that it renders as expected in popup, modal->core content and modal ->video galllery when UI language is changed. Earlier this wasn't the case as the constructor function reponsible for creating the SignItCoreContent (modal->core content) object wasn't being initialized properly. This led to delay in updation of both popup as well as modal when changing UI language.

3. Challenges Faced:

• Challenge : As mentioned above that, passing message for i18n made it an async function which returned promise.So everytime banana.i18n was called , we had to await the promise in order to get its fulfilled result. Now this was easy to deal with in prototype functions as they could be made asynchromous. Main issue was updating the strings inside SignItCoreContent constructor function , as this was can't be made async.

• Solution: In order to load the new language's i18n messages inside the constructor, I made a prototype function, declared it async and then awaited the necessary messsages inside it. After the meessages were resolved , appending the results inside the constructor by accesing the individual elements.

4. Learnings and Skills Gained:

• Learning : got a better understanding of OOPS and Promise constructor function.

5. Goals for Next Week:

I would continue on my previous week's goals as I delved into some other issues this week as mentioned earier which were equally produtive if not better.

Weekly Report (17 June - 23 June)

1. Overview of Tasks Completed:

• Task 1: feat : adding alarms API. The purpose of this PR was to replace timers with alarms API, timers here meaning functions like setTimeout and setInterval. Timers are for more persistent background pages which were used in MV2 but in MV3 , since service_worker is not persistent and it's lifecycle ends and restarts over and over again , alarms API was introduced. This task was the last among the checklist of migrating to service_worker , which has now been achieved after a long due.
• Task 2: Refactor/callbacks to promises. This was another task under API updation. The extension API methods that used callbacks inside our background script had to be replaced with promises. Fortunately subconsciously we were relying on promises throughout our revamp so not much had to be done.

2. Key Accomplishments:

• Accomplishment : Figuring out alarms API and its workaorund. Despite being a single function , figuring it out as per extension's requirement helped a lot.

3. Challenges Faced:

• Challenge : While alarms are cross-browser compatible, achieveing the same in FF turned out to be a tedious task.

• Solution: I kept the old approach as well in order to alteast keep things working. While it makes for an insufficient code , can still be refactored later.

4. Learnings and Skills Gained:

• Learning : Alarms API

5. Goals for Next Week:

• Workinng on local storage persistence issues
• Replacing blocking web request listeners with declarativeNetRequest API

Weekly Report(24 June - 30 June)

1. Overview of Tasks Completed:

• Task : No task was completed this week. Although it is WIP.

2. Challenges Faced:

• Challenge : As mentioned earlier , I chose to replace blocking web request listeners with declarativeNetRequest API. While thought to be working properly , it bugged the youtube site into not playing anything, which ofcourse shouldn't be the case when moving to production.

• Solution: Although I haven't come up with any solution yet, I made some interesting discoveries on why we were modifying the CSP headers and how does declarativeNetRequest API work which I have mentioned down below.

3. Learnings and Skills Gained:

• Learning : The reason we were modifying CSP headers, was , so that if some site allowed video requests from a particular domain like youtube.com,which can further be due to a strict CSP , could also allow videos from wikimedia.commoms in order for our sign video to play. Thanks to Antoinne for shedding the light on the issue who was one of the founding coders of the project.

The declarativeNetRequest API provides a syntactic advantage over what were doing earlier by specifying the rules in a seperate json file and by making some changes in the manifest. It is also more performant and provides extra privacy than webRequestBlocking permission. So good for end users. Although it is currently not possible for us to append headers like we could earlier under declarativeNetRequest API, due to it not being much flexible. Thanks to this conversation right here.

4. Goals for Next Week:

Find and explore workarounds that help us modify CSP headers to allow sites to not restrct videos from our(wikimedia site) domain.

Weekly report (1 July - 7 July)

1. Overview of Tasks Completed:

• Task : web request listener issue resolved

2. Key Accomplishments:

• Accomplishment : resolving the issue without having to deal with headers itself.

3. Challenges Faced:

• Challenge : The reason we were modifying headers was so that our extension's sign language videos could work on sites that have strict CSP headers, like Github or X. As mentioned in previous report I chose to replace old API methods with the newer ones using declarativeNetRequest API. But since it is not yet fully functional , doesn't allow us to append headers , doesn't support regex , I dropped it off and chose to explore other alternatives.

• Solution: I came across iframe tag and its ability to not violate sites' CSP headers since videos were being embedded inside it. While it solved our current problem , it came with a new set of problems that I wish to resolve in the coming week.

4. Learnings and Skills Gained:

• Learning : iframe tag and how we can embed whole documents / html pages inside our DOM.

6. Goals for Next Week:

Goal : Using iframe is certainly fruitious but doing so we cant manipulate the video like we were doing so earlier. The twospeed feature when enabled played our video first at normal speed then a little bit slower (0.75x). But since we can't access the video like we used to , it quite a problem.

Final Report

1. Overview of Tasks Completed:

• Task : Refactor/twospeed

2. Key Accomplishments:

• Accomplishment : I won't say that this is something I accomplished on my own. Infact it was m mentor who came up with the idea of making twospeed work in iframe. Although it indeed is an accomplishment that we get to keep another feature of our extension while making it work on all the sites.

3. Challenges Faced:

• Challenge : Accessing the content document of iframe was the biggest challenge , since the embedded document didn't belong to the parent document iframe was embedded in, it was causing difficulty in accessing the inner elements of the embedded document.

• Solution: That's the twist. My mentor deployed a github page which itself had an iframe to play the video and based on the query parameters present in the URL of the page , we figured what video to play and whether to enable twospeed or not. To enable twospeed we did some pre-processing on the deployed page itself. All that was left to be done was change the <video src> in the extension video component.

4. Learnings and Skills Gained:

• Learning : Workaround that my mentor came up with was quite a learning

All that is left is to publish the extension which is not really in my hands but with this my project has officially ended It was a pleasure to work for LinguaLibre and Wikimedia 🎉🎉