[FEATURE] Standalone Text Translation Input within Extension Popup

[whaliendev]

Before you begin

• I have searched existing issues to avoid duplicates
• I am willing to contribute a PR for this feature

Is your feature request related to a problem? Please describe.

Currently, read-frog excels at in-page context translation. However, it lacks a standalone translation interface for custom user input.

Often, during daily workflows, users need to translate a specific sentence or paragraph they come up with (or copied from an external desktop app). Right now, doing this requires switching contexts to open a separate translation tab (like Google Translate, Gemini, or other llm providers), which breaks the workflow and underutilizes the translation APIs/services already configured within read-frog.

Describe the solution you'd like

Add an independent translation module directly inside the extension's Popup UI.

Expected Behavior:

1. User clicks the read-frog extension icon to open the popup.
2. The popup features a dedicated "Translate" tab or a clearly visible text area.
3. User types or pastes custom text into the input field.
4. The extension leverages the currently configured translation service (and target language settings) to return the translated result immediately within the popup.
5. Provide a quick "Copy" button for the translated output.

This essentially turns the popup into a lightweight, global translation dictionary, significantly enhancing the UX by keeping users within the read-frog ecosystem for all quick translation needs.

Which area(s) would this feature affect? (Select all that apply)

Browser Extension

Additional context

No response

[frogGuaGuaGuaGua]

This feature request makes sense. After looking through the current code structure, I think the more precise framing is not that Read Frog has no standalone text translation at all, but that:

• it already has a dedicated standalone text translation surface: Translation Hub (the popup button opens translation-hub.html)
• it already has a dedicated input translation pipeline, including its own provider config and from/to language config
• but the popup itself is still mainly positioned as a control panel for the current page: page translation toggle, site control, language, provider, prompt, etc.

So I agree with the value of this issue, but I think the core ask is really:

bring the “quick manual translation” capability down into the popup itself, so users do not have to take an extra step into a separate surface.

If this gets implemented later, I think the important question is not “can it be done”, but which existing capability should it build on.

1. Reuse Translation Hub logic

Pros:

• the textarea / translate / copy interaction already exists
• it is already a standalone text-translation surface

Cons:

• Translation Hub is currently more of a multi-provider comparison / experimentation surface
• putting that whole model directly into the popup could make the popup feel too heavy

2. Reuse inputTranslation logic

Pros:

• semantically it is closer to “user manually enters some text and translates it”
• it already has its own inputTranslation.providerId and from/to language settings
• it would make a popup MVP much lighter

Personally, I would lean toward option 2 for an MVP:

• add a lightweight textarea / input panel inside the popup
• bind it to the existing inputTranslation provider and language-direction settings
• support copy in the result area
• if usage proves strong later, then consider adding swap, history, or a more complete tabbed design

There is also one implementation detail worth calling out early:

the popup should probably not inherit the page/article AI-context path directly.

Because the popup is itself an extension page, if we naïvely reuse some page-translation paths, the “context” could end up being the popup’s own UI text rather than the user’s intended external text. In other words, this feature can reuse a lot of the existing translation infrastructure, but at the popup surface it is probably better treated as pure input translation, not as a variant of page translation.

So overall I support the direction, and if someone wants to contribute a PR, I think a clean first step would be:

• add a lightweight input translator inside the popup
• bind it to inputTranslation config first
• do not pull in page/article AI context in the first version

That keeps the scope much more controlled and avoids turning the popup into a smaller duplicate of Translation Hub.

[Yukiniro]

Before you begin

• I have searched existing issues to avoid duplicates[x] I am willing to contribute a PR for this feature

Is your feature request related to a problem? Please describe.

Currently, read-frog excels at in-page context translation. However, it lacks a standalone translation interface for custom user input.

Often, during daily workflows, users need to translate a specific sentence or paragraph they come up with (or copied from an external desktop app). Right now, doing this requires switching contexts to open a separate translation tab (like Google Translate, Gemini, or other llm providers), which breaks the workflow and underutilizes the translation APIs/services already configured within read-frog.

Describe the solution you'd like

Add an independent translation module directly inside the extension's Popup UI.

Expected Behavior:

1. User clicks the read-frog extension icon to open the popup.
2. The popup features a dedicated "Translate" tab or a clearly visible text area.
3. User types or pastes custom text into the input field.
4. The extension leverages the currently configured translation service (and target language settings) to return the translated result immediately within the popup.
5. Provide a quick "Copy" button for the translated output.

This essentially turns the popup into a lightweight, global translation dictionary, significantly enhancing the UX by keeping users within the read-frog ecosystem for all quick translation needs.

Which area(s) would this feature affect? (Select all that apply)

Browser Extension

Additional context

No response

The Translation Hub option in the Settings page should meet your needs.

[whaliendev]

I actually didn't notice this feature until "GuaGuaGua" pointed it out. That's exactly why I feel it's buried way too deep. Sometimes, opening a new tab just loses the context.

[mengxi-ream]

I actually didn't notice this feature until "GuaGuaGua" pointed it out. That's exactly why I feel it's buried way too deep. Sometimes, opening a new tab just loses the context.

Make sense. We gonna have a side panel on the right of the website for translation. Will launch in the future

[frogGuaGuaGuaGua]

Multica issue: REA-13
https://multica.ai/issues/REA-13

[github-actions]

This issue has been inactive for 30 days and is now marked as stale.
It will be automatically closed in 60 days if no further activity occurs.

[mengxi-ream]

#1413

[github-actions]

This issue has been inactive for 30 days and is now marked as stale.
It will be automatically closed in 60 days if no further activity occurs.