what is happening here?

[okias]

From https://github.com/mozilla-extensions/firefox-translations
there is note

This repo has been archived and the work on Firefox Translations will continue here: 
https://github.com/mozilla/firefox-translations

but this repository is empty without any commits, progress or informations.

Would be great if someone clarified what's going on.

[kpu]

I see @andrenatal is developing in https://github.com/andrenatal/firefox-translations .

It seems like a great time to provide an update on your progress @andrenatal

[andrenatal]

The team decided to stop polyfilling in the javascript layer many functionalities that should be part of the translation engine, which caused numerous performance issues reported by internal QA, like this example so we'll push a new version to this repo just when the outstanding functionalities in the translation engine necessary for the front-end are made available to unblock the FE development, including but not limited to:

• Implementation of Inside-outside algorithm for tag translation browsermt/bergamot-translator#199
• https://bugzilla.mozilla.org/show_bug.cgi?id=1720747 and https://bugzilla.mozilla.org/show_bug.cgi?id=1722102 (this was originally responsibility of UEDIN but my team decided to step in and do it ourselves due to long delays)
• Multiple model loading API as discussed here, since it seems the way we are doing now (which is the only way possible) is not the correct one, per the discussion here Wasm test page UI for translating b/w non-English language pairs browsermt/bergamot-translator#231 (review)
• Quality estimation scores browsermt/bergamot-translator#242
• Proper feature request for outbound translations Outbound Translation Requirements browsermt/bergamot-translator#78

We determined that is expensive to continue maintaining the former extension due extensive technical debt, growing incompatibility with Firefox internal architecture for a system component, and lack of proper documentation, and for that I reason I'll continue to develop the new version on my own fork until we are unblocked by the aforementioned issues and are certain that those are working as intended before turning it into an official replacement in this repo.

[kpu]

* https://bugzilla.mozilla.org/show_bug.cgi?id=1720747 and https://bugzilla.mozilla.org/show_bug.cgi?id=1722102 (this was originally responsibility of UEDIN but my team decided to step in and do it ourselves due to long delays)

You don't get to unilaterally impose WebAssembly then call the resulting slowness UEDIN's responsibility.

[andrenatal]

Thanks for you comment @kpu, but we decided to utilize such architecture since in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1713056#c3 you confirmed your willingness to collaborate with us on this matter.

[andrenatal]

I'm closing this since it's not actually an issue and I don't want to start yet another flame war over github issues like all the other numerous unfruitful ones. If you have questions, feel free to send me an email and we can jump in a call right away, except of weekends.