Added Streamlit Translator Demo App #1851
Conversation
|
hi your PR is missing changeset. Please add the changeset by following instructions here. Make sure you've joined our discord to see this message. If you haven't you need to:
Please also sign your commits Lastly, your readme is a copy of the community space readme. It needs to be about your project 😀 Please update it. |
|
Hey @laibaishfaq108-blip! Just checking in - are you still working on this PR? We noticed there are some comments that may need addressing. If you need more time, no problem! Just let us know. If we don't hear back within a week, we'll close this to keep the repo tidy, but you can always reopen when ready. |
📝 WalkthroughWalkthroughAdds a new Streamlit translator app and its README and requirements; removes the top-level Changes
Sequence Diagram(s)sequenceDiagram
participant User as User
participant App as Streamlit App
participant GT as GoogleTranslator
User->>App: Enter text + select language\nClick "Translate"
App->>App: validate input\nshow spinner
App->>GT: translate(text, target)
GT-->>App: translation result
App-->>User: display translation (text area + code block)\nshow success message
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@community/py-streamlit-translator/app.py`:
- Around line 9-22: The Clear button currently calls st.rerun() which doesn't
reset the st.text_area and trying to set st.session_state after rendering will
raise a StreamlitAPIException; fix this by giving the text area a key (e.g.,
"input_text") via st.text_area(..., key="input_text") and implement a
clear_input callback (e.g., def clear_input(): st.session_state["input_text"] =
"") then attach it to the Clear button using st.button("Clear 🧹",
on_click=clear_input) so the widget state is cleared correctly; alternatively
consider using st.form with clear_on_submit=True for a submit-and-clear flow.
- Around line 23-31: Wrap the call to GoogleTranslator(...).translate(text) in a
try/except that specifically catches deep_translator.exceptions.TooManyRequests
and a general Exception, display a user-facing st.error like "Translation
failed. Please try again in a moment." (do not call st.stop()), and set
translated to None when an error occurs so the subsequent success/display block
only runs if translated is truthy; update the block referencing
GoogleTranslator, translated, and do_translate accordingly.
In `@community/py-streamlit-translator/README.md`:
- Around line 30-60: Update README.md to fix unbalanced code fences and make the
clone/install steps repo-specific: replace the placeholder git clone with the
monorepo URL and correct subfolder path (use git clone
https://github.com/lingodotdev/lingo.dev.git then cd
lingo.dev/community/py-streamlit-translator), wrap the Clone, Install
dependencies, and Run the app commands each in proper ```bash fenced blocks, and
ensure headings like "## 📂 Project Structure" and "## 🙌 Contribution" include
a space after the emoji for consistent markdown rendering; locate these edits in
the README.md content for py-streamlit-translator.
In `@community/py-streamlit-translator/requirements.txt`:
- Around line 1-3: requirements.txt is missing the deep-translator package
required by app.py (it imports deep_translator.GoogleTranslator); add the
dependency "deep-translator" to requirements.txt so the import
deep_translator.GoogleTranslator in app.py resolves at runtime and prevents
ImportError.
- Around line 1-3: The Streamlit dependency in requirements.txt pulls a protobuf
version in the vulnerable range; to mitigate, locate any codepaths that parse
protobuf JSON (search for usages of google.protobuf.json_format.ParseDict,
Parse, MessageToJson, or any code handling google.protobuf.Any) and replace
direct ParseDict calls with a safe wrapper that first validates input: enforce a
maximum JSON nesting depth, reject or strip Any fields, and disallow untrusted
JSON before calling protobuf parsers; add defensive checks where streamlit-based
components accept user JSON input and document/monitor
protocolbuffers/protobuf#25239 to upgrade protobuf to a patched release as soon
as it is published.
🧹 Nitpick comments (1)
community/py-streamlit-translator/README.md (1)
3-5: Align README with actual dependency and fix typo.There’s a stray
*at Line 3, and the Tech Stack listsgoogletranseven though the app usesdeep_translator. This can confuse contributors about the actual dependency.✏️ Suggested edits
-A simple and interactive Translator web app built using **Python + Streamlit**.* +A simple and interactive Translator web app built using **Python + Streamlit**. @@ -- deep-translator / googletrans +- deep-translator (GoogleTranslator)Also applies to: 21-24
| text = st.text_area("Write text", height=120, placeholder="e.g., Hello how are you?") | ||
|
|
||
| lang = st.selectbox("Translate to", ["Urdu", "Hindi", "Arabic"]) | ||
| target_map = {"Urdu": "ur", "Hindi": "hi", "Arabic": "ar"} | ||
| target = target_map[lang] | ||
|
|
||
| col1, col2 = st.columns(2) | ||
| with col1: | ||
| do_translate = st.button("Translate ✅") | ||
| with col2: | ||
| clear = st.button("Clear 🧹") | ||
| if clear: | ||
| st.rerun() | ||
|
|
There was a problem hiding this comment.
❓ Verification inconclusive
Streamlit st.rerun widget state reset clear text input
To clear/reset a st.text_input when you call st.rerun(), you generally need to avoid trying to change the widget’s value after it’s already been rendered in the current run (Streamlit will block/ignore that pattern). (docs.streamlit.io)
Option A (recommended): put the input in a form and use clear_on_submit=True
This is the cleanest “clear after submit” behavior and works well with st.rerun() to refresh other UI. (docs.streamlit.io)
import streamlit as st
with st.form("my_form", clear_on_submit=True):
q = st.text_input("Query")
submitted = st.form_submit_button("Search")
if submitted:
# do something with q
st.rerun()Option B: force a new widget identity by changing the key
Changing the key makes Streamlit treat it as a new widget, so it appears empty again. (This aligns with Streamlit’s widget identity/lifecycle rules.) (docs.streamlit.io)
import streamlit as st
st.session_state.setdefault("txt_ver", 0)
k = f"q_{st.session_state.txt_ver}"
q = st.text_input("Query", key=k)
if st.button("Clear"):
st.session_state.txt_ver += 1
st.rerun()Option C: delete the session_state entry before rendering the widget
Deleting session state is supported, but make sure the deletion happens before the widget is created in that run. (docs.streamlit.io)
import streamlit as st
if st.session_state.get("do_clear"):
st.session_state.pop("q", None)
st.session_state.do_clear = False
q = st.text_input("Query", key="q")
if st.button("Clear"):
st.session_state.do_clear = True
st.rerun()If you share a small snippet of your current code (especially where st.rerun() is called), I can point to the exact minimal change.
Citations:
- 1: https://docs.streamlit.io/develop/concepts/design/buttons?utm_source=openai
- 2: https://docs.streamlit.io/1.43.0/develop/api-reference/execution-flow/st.form?utm_source=openai
- 3: https://docs.streamlit.io/develop/concepts/architecture/widget-behavior?utm_source=openai
- 4: https://docs.streamlit.io/develop/api-reference/caching-and-state/st.session_state?utm_source=openai
Streamlit session_state widget key clear text_area
To clear an st.text_area that’s tied to st.session_state, you must update its key’s value before the widget is instantiated in the next rerun—typically via a callback (don’t set st.session_state[ta_key] = "" inside the if st.button(...): block after the widget renders, or you’ll hit StreamlitAPIException). [5], [3]
Pattern: use on_click/on_change callback to reset the widget key
import streamlit as st
TA_KEY = "msg"
def clear_text_area():
st.session_state[TA_KEY] = ""
# Initialize (optional but common)
st.session_state.setdefault(TA_KEY, "")
st.button("Clear", on_click=clear_text_area)
st.text_area("Message", key=TA_KEY)This works because callbacks run first, then Streamlit reruns the script top-to-bottom, and the widget reads the updated st.session_state[TA_KEY]. [1], [5], [3]
Alternative: force a reset by changing the widget key
If you change the widget’s key (e.g., add a counter suffix), Streamlit treats it as a new widget and it resets. [1]
Sources: Streamlit docs on widget behavior and button-driven resets [1], [5], session_state usage/limitations [2], and a working community example clearing text_area via callback [3].
Streamlit rerun behavior widget persistence state management
Streamlit’s execution model is: your script reruns top-to-bottom on (most) widget interactions, and you manage persistence via widget keys + st.session_state.
Reruns: what triggers them
- Widgets outside a form: changing a value triggers an immediate rerun (for text/number inputs, typically on blur/tab-out or Enter). [1]
- Widgets inside
st.form(...): changes don’t reach Python and don’t rerun until the user submits the form (viast.form_submit_button). [1]
Widget state & callbacks: order of operations
On interaction, Streamlit updates state and reruns in this order:
- the widget value in
st.session_stateis updated - the widget callback runs (if any)
- the script reruns, and the widget call returns the new value [2]
Persistence rules (the part that surprises people)
- Widgets persist only if they are continuously rendered. If a widget isn’t called on a run (e.g., you hide it behind an
if, switch pages, etc.), Streamlit drops its state—including itsst.session_state[key]entry—and when it reappears it’s treated as a new widget. [2] - Browser refresh / full reload resets Session State, because it’s tied to the session’s WebSocket connection. [3]
Practical state-management patterns
- Give widgets stable
key=values so their values are tracked inst.session_stateacross reruns. (st.session_state[key]is the “source of truth” for that widget’s value.) [3] - Initialize non-widget state once:
(Session State exists specifically because normal Python variables reset every rerun.) [4]
if "filters" not in st.session_state: st.session_state.filters = {}
- Use forms to “batch” multiple widget edits into one rerun on submit. [1]
- Avoid trying to set a widget’s value in
st.session_stateafter you’ve already instantiated that widget in the same run—Streamlit will raise an exception; set defaults before creating the widget, and then read/act on state afterward. [3]
If you describe your specific case (e.g., “a widget disappears when a checkbox is off” / “multipage app” / “I need values to survive refresh”), I can suggest the cleanest pattern for it.
Clear button doesn't actually clear widget state—and the suggested approach will fail.
st.rerun() alone won't reset st.text_area state; the previous input will persist. However, setting st.session_state after the widget has already rendered (as in the suggested fix) will raise a StreamlitAPIException. Instead, use a callback:
def clear_input():
st.session_state["input_text"] = ""
text = st.text_area(
"Write text",
height=120,
placeholder="e.g., Hello how are you?",
key="input_text",
)
col1, col2 = st.columns(2)
with col1:
do_translate = st.button("Translate ✅")
with col2:
clear = st.button("Clear 🧹", on_click=clear_input)Alternatively, use st.form with clear_on_submit=True for a cleaner "clear after submit" pattern.
🤖 Prompt for AI Agents
In `@community/py-streamlit-translator/app.py` around lines 9 - 22, The Clear
button currently calls st.rerun() which doesn't reset the st.text_area and
trying to set st.session_state after rendering will raise a
StreamlitAPIException; fix this by giving the text area a key (e.g.,
"input_text") via st.text_area(..., key="input_text") and implement a
clear_input callback (e.g., def clear_input(): st.session_state["input_text"] =
"") then attach it to the Clear button using st.button("Clear 🧹",
on_click=clear_input) so the widget state is cleared correctly; alternatively
consider using st.form with clear_on_submit=True for a submit-and-clear flow.
| if do_translate: | ||
| if text.strip() == "": | ||
| st.warning("Please write something first.") | ||
| else: | ||
| with st.spinner("Translating..."): | ||
| translated = GoogleTranslator(source="auto", target=target).translate(text) | ||
| st.success("Done!") | ||
| st.text_area("Translation", value=translated, height=120) | ||
| st.code(translated, language="text") |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f -name "app.py" | head -20Repository: lingodotdev/lingo.dev
Length of output: 107
🏁 Script executed:
cd community/py-streamlit-translator 2>/dev/null && ls -laRepository: lingodotdev/lingo.dev
Length of output: 357
🏁 Script executed:
cd community/py-streamlit-translator 2>/dev/null && cat -n app.py | head -50Repository: lingodotdev/lingo.dev
Length of output: 1381
🌐 Web query:
GoogleTranslator google-translator-py exceptions raises errors
💡 Result:
GoogleTranslator is used by multiple Python packages, so the exact exceptions depend on which one you installed (the name google-translator-py is ambiguous). The most common ones people hit are:
Exception: Unexpected status code "429"(rate-limited / blocked) — happens with unofficial “scrape” clients; often indicates Google is throttling/banning your IP. Seen ingoogletrans/py-googletrans. [1]- HTTP 5xx / “banned client IP” symptoms —
googletransexplicitly warns that 5xx (and similar) can mean your client IP was banned. [2] - Async misuse warnings/errors — newer
googletransversions are async; callingTranslator.translate()withoutawaitleads to runtime warnings and broken behavior. [3] - Library-specific “too many requests” exceptions — e.g.,
deep-translator’s ecosystem can raiseTooManyRequestswhen providers throttle you. [4] - Old-version attribute errors — e.g.,
AttributeError: 'Translator' object has no attribute 'raise_Exception'occurred in oldergoogletransprereleases. [1]
If you paste (a) pip show google-translator-py output (or the exact package name/version) and (b) the full traceback, I can map your error to the exact exception type and the right fix.
🏁 Script executed:
cat community/py-streamlit-translator/requirements.txtRepository: lingodotdev/lingo.dev
Length of output: 100
🌐 Web query:
deep_translator GoogleTranslator exceptions TooManyRequests documentation
💡 Result:
deep_translator documents a dedicated exception class for GoogleTranslator rate-limiting:
- Exception:
deep_translator.exceptions.TooManyRequests(a plainExceptionsubclass). It’s documented with the default message indicating Google rate limits (e.g., ~5 requests/sec and up to 200k/day) and suggests waiting/retrying or usingtranslate_batch. [1] - When it’s raised (GoogleTranslator): when Google responds with HTTP 429 (rate limiting). [2]
Minimal usage:
from deep_translator import GoogleTranslator
from deep_translator.exceptions import TooManyRequests
try:
GoogleTranslator(source="auto", target="en").translate("Hola")
except TooManyRequests as e:
# backoff + retry, or switch to translate_batch / another provider
print(e)Sources: deep-translator exceptions docs [1] and GoogleTranslator error-handling notes [2].
References:
[1] (deep-translator.readthedocs.io)
[2] (deepwiki.com)
Citations:
- 1: https://deep-translator.readthedocs.io/en/stable/_modules/deep_translator/exceptions.html
- 2: https://deepwiki.com/nidhaloff/deep-translator/3.1-google-translator?utm_source=openai
🌐 Web query:
Streamlit st.stop() error handling best practice
💡 Result:
Best practice for handling st.stop() in Streamlit
-
Use
st.stop()for control flow, not “error handling.” It’s meant for early-exit/guard clauses (e.g., missing input). Streamlit recommends you render a user-facing message first, then stop. [1]if not name: st.warning("Please enter a name.") st.stop()
-
Assume
st.stop()works by raising an internal “stop” exception. Seeing something likestreamlit.runtime.scriptrunner.exceptions.StopExceptioncan happen in debuggers/logs or if something intercepts it; it’s normal that stopping execution is implemented via an exception. [2] -
Don’t accidentally catch it with broad exception handlers.
- Avoid
except BaseException:(orbare except:) around code that may callst.stop()(or other Streamlit control-flow like reruns), because you can swallow the control-flow signal and end up in a broken state. - If you must have a broad handler, re-raise Streamlit’s control-flow exceptions (stop/rerun) and only handle “real” errors.
- Avoid
-
Be extra careful with
try/exceptaround Streamlit control-flow. Streamlit has had version-specific edge cases where control-flow APIs misbehave insidetry/except(documented forst.rerunin 1.37). Keepingst.stop()(andst.rerun) outside broadtry/exceptblocks is the safest pattern. [3] -
For “real” errors, prefer catching specific exceptions and showing UI, rather than sprinkling
st.stop()everywhere. If you find yourself doingst.error(...); st.stop()repeatedly, consider centralizing error-to-UI handling (an “error boundary” style) to keep app logic clean. [4]
Sources: Streamlit st.stop docs [1]; Streamlit forum discussion of StopException from st.stop() [2]; Streamlit GitHub issue on control-flow inside try/except (st.rerun) [3]; community “error boundary” approach noting Streamlit control-flow exceptions should pass through [4].
Add error handling for GoogleTranslator API failures.
GoogleTranslator can raise deep_translator.exceptions.TooManyRequests (rate limiting) and other exceptions. The current code will crash if the API fails or is throttled. Add a try/except block, but avoid st.stop() inside the exception handler (Streamlit control-flow can misbehave). Instead, catch the exception, display an error message, and let the user retry.
🛡️ Suggested error handling
if do_translate:
if text.strip() == "":
st.warning("Please write something first.")
else:
with st.spinner("Translating..."):
try:
translated = GoogleTranslator(source="auto", target=target).translate(text)
except Exception as e:
st.error("Translation failed. Please try again in a moment.")
translated = None
if translated:
st.success("Done!")
st.text_area("Translation", value=translated, height=120)
st.code(translated, language="text")🤖 Prompt for AI Agents
In `@community/py-streamlit-translator/app.py` around lines 23 - 31, Wrap the call
to GoogleTranslator(...).translate(text) in a try/except that specifically
catches deep_translator.exceptions.TooManyRequests and a general Exception,
display a user-facing st.error like "Translation failed. Please try again in a
moment." (do not call st.stop()), and set translated to None when an error
occurs so the subsequent success/display block only runs if translated is
truthy; update the block referencing GoogleTranslator, translated, and
do_translate accordingly.
| Clone the repo: | ||
|
|
||
| ```bash | ||
| git clone <your-repo-url> | ||
| cd py-streamlit-translator | ||
| Install dependencies: | ||
|
|
||
| **Bash** | ||
|
|
||
| pip install -r requirements.txt | ||
| Run the app: | ||
|
|
||
| **Bash** | ||
| streamlit run app.py | ||
|
|
||
| ## 💻 Usage: | ||
|
|
||
| Enter text | ||
| Select source language | ||
| Select target language | ||
| Click Translate | ||
| Get instant results 🎉 | ||
|
|
||
| ##📂 Project Structure | ||
|
|
||
| py-streamlit-translator/ | ||
| │── app.py | ||
| │── requirements.txt | ||
| │── README.md | ||
|
|
||
| ##🙌 Contribution |
There was a problem hiding this comment.
Fix markdown formatting and make install steps repo-specific.
The installation section’s code fences are unbalanced, and the placeholder repo URL conflicts with the monorepo structure. Also, headings like ##📂 / ##🙌 should include a space for consistent markdown rendering.
🧩 Suggested README cleanup
-Clone the repo:
-
-```bash
-git clone <your-repo-url>
-cd py-streamlit-translator
-Install dependencies:
-
-**Bash**
-
-pip install -r requirements.txt
-Run the app:
-
-**Bash**
-streamlit run app.py
+Clone the repo:
+
+```bash
+git clone https://github.com/lingodotdev/lingo.dev.git
+cd lingo.dev/community/py-streamlit-translator
+```
+
+Install dependencies:
+
+```bash
+pip install -r requirements.txt
+```
+
+Run the app:
+
+```bash
+streamlit run app.py
+```
@@
-##📂 Project Structure
+## 📂 Project Structure
@@
-##🙌 Contribution
+## 🙌 Contribution📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Clone the repo: | |
| ```bash | |
| git clone <your-repo-url> | |
| cd py-streamlit-translator | |
| Install dependencies: | |
| **Bash** | |
| pip install -r requirements.txt | |
| Run the app: | |
| **Bash** | |
| streamlit run app.py | |
| ## 💻 Usage: | |
| Enter text | |
| Select source language | |
| Select target language | |
| Click Translate | |
| Get instant results 🎉 | |
| ##📂 Project Structure | |
| py-streamlit-translator/ | |
| │── app.py | |
| │── requirements.txt | |
| │── README.md | |
| ##🙌 Contribution | |
| Clone the repo: | |
🤖 Prompt for AI Agents
In `@community/py-streamlit-translator/README.md` around lines 30 - 60, Update
README.md to fix unbalanced code fences and make the clone/install steps
repo-specific: replace the placeholder git clone with the monorepo URL and
correct subfolder path (use git clone
https://github.com/lingodotdev/lingo.dev.git then cd
lingo.dev/community/py-streamlit-translator), wrap the Clone, Install
dependencies, and Run the app commands each in proper ```bash fenced blocks, and
ensure headings like "## 📂 Project Structure" and "## 🙌 Contribution" include
a space after the emoji for consistent markdown rendering; locate these edits in
the README.md content for py-streamlit-translator.
| streamlit | ||
| lingodotdev | ||
| python-dotenv No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the app.py file and check its imports
fd -type f -name "app.py" | head -20Repository: lingodotdev/lingo.dev
Length of output: 235
🏁 Script executed:
# Also check the directory structure to understand the project layout
git ls-files | grep -E "(requirements|setup|pyproject|app)" | head -30Repository: lingodotdev/lingo.dev
Length of output: 775
🏁 Script executed:
cat -n "community/py-streamlit-translator/app.py"Repository: lingodotdev/lingo.dev
Length of output: 1381
🏁 Script executed:
cat -n "community/py-streamlit-translator/requirements.txt"Repository: lingodotdev/lingo.dev
Length of output: 121
🏁 Script executed:
# Check if there are any other dependency files in that directory
ls -la "community/py-streamlit-translator/"Repository: lingodotdev/lingo.dev
Length of output: 357
Add missing deep-translator dependency.
app.py imports deep_translator.GoogleTranslator on line 2 and uses it on line 28, but the package is not listed in requirements.txt. This will cause a runtime ImportError when running the application.
🩹 Proposed update
streamlit
lingodotdev
python-dotenv
+deep-translator📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| streamlit | |
| lingodotdev | |
| python-dotenv | |
| streamlit | |
| lingodotdev | |
| python-dotenv | |
| deep-translator |
🧰 Tools
🪛 OSV Scanner (2.3.2)
[HIGH] 1-1: protobuf 6.33.4: protobuf affected by a JSON recursion depth bypass
🤖 Prompt for AI Agents
In `@community/py-streamlit-translator/requirements.txt` around lines 1 - 3,
requirements.txt is missing the deep-translator package required by app.py (it
imports deep_translator.GoogleTranslator); add the dependency "deep-translator"
to requirements.txt so the import deep_translator.GoogleTranslator in app.py
resolves at runtime and prevents ImportError.
🧩 Analysis chain
🌐 Web query:
GHSA-7gcm-g887-7qv7 protobuf vulnerability
💡 Result:
GHSA-7gcm-g887-7qv7 (CVE-2026-0994) is a DoS vulnerability in Python protobuf’s JSON parsing: google.protobuf.json_format.ParseDict() can bypass max_recursion_depth when parsing deeply nested google.protobuf.Any messages, eventually exhausting Python’s recursion stack (raising RecursionError) and crashing the process. Severity: High (CVSS 8.2). [1][2]
Affected: PyPI protobuf all versions <= 6.33.4. [1][2][3]
Fix status: As of the advisory publication (Jan 23, 2026), no patched version is listed; the upstream fix is being worked via PR protocolbuffers/protobuf#25239. [1][2][4]
Mitigations (until a release is available):
- Avoid using
json_format.ParseDict()/ JSON-to-protobuf on untrusted JSON, especially when messages can includeAny. [1][2] - If you must accept JSON: add your own input validation (cap nesting depth / reject or strictly whitelist
Anyusage) before calling protobuf JSON parsing. (Derived from the described root cause and attack.) [1][2]
Sources: [1] GitHub Advisory Database, [2] OSV entry, [3] PyPI release history showing 6.33.4, [4] upstream fix PR.
🏁 Script executed:
#!/bin/bash
# Check if we can determine streamlit's dependencies
# First, let's see what files are in the repository context
git ls-files community/py-streamlit-translator/ | head -20Repository: lingodotdev/lingo.dev
Length of output: 200
🏁 Script executed:
#!/bin/bash
# Read the complete requirements.txt file
cat -n community/py-streamlit-translator/requirements.txtRepository: lingodotdev/lingo.dev
Length of output: 121
🌐 Web query:
streamlit protobuf dependency version
💡 Result:
- Latest Streamlit on PyPI:
streamlit==1.53.1(released Jan 22, 2026). [1] - Protobuf compatibility (by Streamlit version):
- Streamlit 1.35.0 had the dependency constraint
protobuf>=3.20,<5(so protobuf 5.x would be rejected by pip). [2] - Streamlit later added support for
protobufv5, so newer Streamlit versions are intended to work with protobuf 5.x. [3]
- Streamlit 1.35.0 had the dependency constraint
If you’re trying to resolve an environment conflict, the key takeaway is: protobuf 5.x requires a Streamlit version new enough to support protobuf 5; older Streamlit versions (e.g., 1.35.0) will force protobuf <5. [2][3]
Sources: [1] [2] [3]
🌐 Web query:
streamlit 1.53.1 requirements protobuf version constraint
💡 Result:
For Streamlit 1.53.1, the protobuf dependency constraint is:
protobuf >= 3.20, < 5(i.e., protobuf 5.x is not allowed). [1][2]
Sources: Streamlit dependency conflict reports explicitly show streamlit … depends on protobuf<5 and >=3.20. [1][2]
Audit transitive protobuf vulnerability in Streamlit dependency.
Streamlit requires protobuf >= 3.20, < 5, which falls within the vulnerable range for GHSA-7gcm-g887-7qv7 (HIGH severity DoS in JSON parsing). This vulnerability affects all protobuf versions ≤ 6.33.4, and no patched version is currently available (upstream fix is in progress as of January 2026).
Until a patched release is available:
- Avoid using
google.protobuf.json_format.ParseDict()on untrusted JSON input, especially with messages containinggoogle.protobuf.Anyfields. - If JSON parsing is necessary, implement input validation to cap nesting depth and restrict or reject
Anyusage before calling protobuf JSON parsing functions.
Monitor the upstream fix (protocolbuffers/protobuf#25239) for a patched release and upgrade when available.
🧰 Tools
🪛 OSV Scanner (2.3.2)
[HIGH] 1-1: protobuf 6.33.4: protobuf affected by a JSON recursion depth bypass
🤖 Prompt for AI Agents
In `@community/py-streamlit-translator/requirements.txt` around lines 1 - 3, The
Streamlit dependency in requirements.txt pulls a protobuf version in the
vulnerable range; to mitigate, locate any codepaths that parse protobuf JSON
(search for usages of google.protobuf.json_format.ParseDict, Parse,
MessageToJson, or any code handling google.protobuf.Any) and replace direct
ParseDict calls with a safe wrapper that first validates input: enforce a
maximum JSON nesting depth, reject or strip Any fields, and disallow untrusted
JSON before calling protobuf parsers; add defensive checks where streamlit-based
components accept user JSON input and document/monitor
protocolbuffers/protobuf#25239 to upgrade protobuf to a patched release as soon
as it is published.
|
Hi, I've completed the updates and pushed the changes |
2 participants
Summary
Added a simple Streamlit Translator demo app to the community directory.
Changes
Closes #[1761]
Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.