Update Estonian translation
Update Estonian translation
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Priit Jõerüüt <jrthwlate@users.noreply.hosted.weblate.org>
Some YouTube videos like https://www.youtube.com/watch?v=Ajkr_Wg-k8g
had an non comment key that was inside the Array that contained some
comment information that Invidious parses (like comment_key and
toolbar_key), that being the `commentFilterContextViewModel` key, which
is just an indicator on how comments are sorted:
```
{
"commentThreadRenderer": { ... } <- comment information that is
handled by line 134 of youtube.cr
},
{
"commentFilterContextViewModel": {
"text": {
"content": "Top is selected, so you'll see featured comments"
},
"accessibility": {
"accessibilityData": {
"label": "Top is selected, so you'll see featured comments"
}
}
} <- Useless information, this is not a comment
}
```
Three parsers know for certain that an item is a Short and then discard the fact:
- `ShortsLockupViewModelParser` and `ReelItemRendererParser` only ever run on a
shorts renderer, so every item they produce is a Short by construction.
- `VideoRendererParser` reads a thumbnail overlay whose text is the literal
"SHORTS" in place of a duration. Its own TODO asks for this: "Add some sort of
metadata for the type of video (normal, live, premiere, shorts)".
All three emit `VideoBadges::None`, so nothing downstream can tell a Short from a
normal video. What makes that costly is the duration: YouTube no longer reports a
real one for Shorts and these parsers substitute an approximate 60s (as their own
NOTE says), so the only signals left to a client are a length indistinguishable
from a genuine 60-second upload, and a "#shorts" title tag that is a convention
rather than metadata. Measured: all 48 items on a channel's Shorts tab report
exactly `lengthSeconds: 60`, and on a live search 4 of 20 results carried
"#shorts" while running 8-27 minutes.
Add a `Shorts` badge, set it in all three parsers, and serialise it as `isShort`
alongside the existing `isUpcoming` / `isNew` / `is4k` flags. `Shorts` is appended
to the flags enum rather than inserted, since these are bit values and reordering
would change the meaning of an already-persisted badge set.
AI disclosure, per AI_POLICY.md: this patch was written with AI assistance.
Exact model: Claude Opus 5, model ID `claude-opus-5[1m]`. Tool used to interact
with it: Claude Code, Anthropic's agentic CLI. The change was verified against a
live patched instance (see the PR for the measurements) and is running in
production on the submitter's instance. Submitted by and the responsibility of
@mdbraber.
* Various enhancements and rewording to the issues/PRs templates
* Remove the "explain how" from the checkboxes since the explanation is
below
* Make the checkbox valid markdown so that they don't appear as text next
to the rendered checked one
* Add comma to make the sentences flow better
* Consistency
* Convert issue templates to Issue Forms with AI policy disclosure
Convert the 3 markdown issue templates (.md) to GitHub Issue Forms (.yml)
to enable interactive form elements, and add an AI disclosure section per
the AI Policy (AI_POLICY.md):
- Required checkbox to acknowledge having read the AI Policy
- Required dropdown for AI usage (none / fully / partially with explanation)
- Optional input for model(s) used (open-weight examples in placeholder)
- Optional input for tool(s) used (FOSS examples in placeholder)
- Optional textarea to explain how AI was used (for the partial option)
The existing template content and structure is preserved, only converted
from markdown to the Issue Forms schema.
* Align pull request template with AI policy disclosure
Update the pull request template to match the AI disclosure standards
introduced in the issue templates:
- Use relative link to AI_POLICY.md instead of absolute GitHub URL
- Update dropdown wording to match issue forms
- Use open-weight models in placeholder examples
- Use FOSS tools in placeholder examples
- Add 'How was AI used?' section for the partial-usage explanation
* Fix assignees field type in issue templates
Use an empty array instead of an empty string for the assignees field,
as required by the GitHub Issue Forms schema.
* Enhance the PR template
* Reword the issue templates to be consistent with the PR template
* Enhance the PR template
* Typo coming from the original template
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Better wording for what comes from the original templates
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Switch to full URLs since relative URL break inconsistently
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Create AI_POLICY.md
* Add some more
* Typo
* Update AI_POLICY.md
Co-authored-by: Émilien (perso) <4016501+unixfox@users.noreply.github.com>
* Various minor enhancements
* Various small rewording
* Add a line about it being mostly done by the maintainers
---------
Co-authored-by: Émilien (perso) <4016501+unixfox@users.noreply.github.com>
* Add option to disable easy to abuse API endpoints
The API endpoints that will be disabled when this option are:
- /api/v1/videos
- /api/v1/clips
- /api/v1/transcripts
There is still API endponts that need some sort of validation or
connection/proxying to Invidious companion like
`/api/v1/captions` and `/api/v1/storyboards` since they also do a video
request to Invidious companion. I'm not sure if the `/next` API endpoint
could be used to gather that type of information, if so, that would be
better.
Closes#5599
* Rename configuration variable, add additional comment for the option
