# sd-webui-prompt-all-in-one is declared unmaintained and already has a successor

> A browser extension for the stable-diffusion web interface that replaces the plain prompt boxes with bilingual comparison, translation across dozens of online services, history, favourites and weight adjustment. Its author has stated in bold that it will no longer be maintained, has pointed readers at a separate standalone application, and has committed a backup config file and a broken licence badge along the way.

**Physton/sd-webui-prompt-all-in-one** — This is an extension based on sd-webui, aimed at improving the user experience of the prompt/negative prompt input box. It has a more intuitive and powerful input interface function, and provides automatic translation, history record, and bookmarking functions.    这是一个基于 sd-webui 的扩展，旨在提高提示词/反向提示词输入框的使用体验。它拥有更直观、强大的输入界面功能，它提供了自动翻译、历史记录和收藏等功能。

- Repository: https://github.com/Physton/sd-webui-prompt-all-in-one
- Website: https://aiodoc.physton.com
- Stars: 3,239 · Forks: 292
- Language: Python
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/physton-sd-webui-prompt-all-in-one

## The author has declared the project unmaintained and still takes pull requests

The most important line in this readme is a bold paragraph with three envelope markers in front of it, and it is a farewell.

It says the author is sorry, that personal energy is limited, and that the project will no longer be maintained. It then invites anyone who improves the code to submit a pull request, and says the author will find time to merge it into the main branch.

So the project is not archived, and the branch was last pushed in September 2026. Those are the two facts a reader can verify from the repository's own metadata, and they sit alongside an explicit statement that no maintenance is happening.

That combination is unusual and worth handling carefully rather than resolving. An unarchived repository with a recent push and an author saying they will merge when they can is not the same as a maintained project, and it is not the same as an abandoned one either.

For anyone depending on it, the practical reading is that features will not appear and bugs will not be fixed, and that the merge window depends on one person's spare time. The extension is not going to break tomorrow, and it is not going to improve next month.

## There is already a standalone successor, in another repository

The readme does not leave the deprecation hanging, because it points somewhere.

A second announcement, styled with megaphone markers, says the project has developed an independent standalone version that runs without depending on the web interface at all. It describes that version as lightweight and compact, focused on editing and organising prompt words, and links to a separate repository under the same author for its tutorial.

So the shape is: a feature-rich extension for the web interface, and a smaller standalone application that does not need it. The author is effectively recommending the second one.

That matters for evaluation. If what you want is a prompt organiser, the standalone version has fewer moving parts and no dependency on the host application. If what you want is the extension's integration, particularly the bilingual prompt comparison that sits next to the generated image, then you are choosing the unmaintained option knowingly.

The documentation site reinforces the split, because it carries a page describing extension updates separately from the installation pages, which suggests the extension still receives the occasional new release even after the maintenance statement.

## Keyless translation services are documented as unstable, and bug reports are forbidden

The translation feature is documented in three tiers, and the first tier has the most interesting caveat in the whole readme.

The tier that requires no key is described as highly unstable, with the note that not every such service can be used on your computer, and the instruction that if translation fails you should try switching to another one. Then, in bold with three warning markers, the readme says not to submit an issue.

So the default path for a user with no configuration is: your prompt text is sent to a free third party endpoint, the endpoint may not work, and the failure is explicitly not a bug.

The second tier needs your own key, which you apply for yourself, and the readme notes that most of them are free. Its methods appear only after you switch to the corresponding interface.

The third tier is the one that keeps everything on your machine, and it has a cost of its own: language models are downloaded automatically during initialisation, so a poor network connection means initialisation may never complete.

That is three genuinely different privacy and reliability postures behind one feature, and the readme does distinguish them. What it does not do is say which tier is the default.

## The translation language list includes Klingon twice

The readme has two collapsible lists, one for interface languages and one for translation languages, and the second one is enormous.

The interface list has twelve entries. The translation list runs to well over a hundred, and it contains entries you would not design by hand.

There are two entries for Klingon, one written in the standard transliteration and one in a constructed alphabet, which means the catalogue distinguishes them the way the underlying service does rather than merging them. There is an entry in Toki Pona, one in a constructed interlanguage, one in Dʼni, one in Reo Tahiti, one in Tok Pisin, one in Quechua with a regional tag, one in Hmong, and two separate Inuktitut entries distinguished by script. There is a language labelled with a name in one script and a country in another, in several cases.

This is not a curated list. It is a machine-translation vendor's full catalogue pasted in, complete with its own naming conventions and its regional tags.

That is a reasonable engineering shortcut and it explains the breadth honestly: the project can translate into these languages because the service it calls supports them, not because anyone verified the labels. The truncated line in the middle of the list, ending mid-entry, is what a pasted catalogue looks like in a repository.

## The licence badge points at a branch and a filename that do not exist

The row of badges at the top of the readme has six links, and one of them cannot work.

The licence badge points at a path on the master branch for a licence file with a markdown extension. The repository's default branch is main, not master, and the root listing shows a licence file with no extension at all.

So the badge resolves through a branch that does not exist onto a filename that does not exist. A reader who wants to check the terms before installing has two other routes, since the description line at the top of the readme names the licence in words, and the file is one click away in the tree. It is the badge, the machine-readable route, that is broken.

The other five badges are fine and they are not all what you would expect. There are badges for stars, for the network graph, for issues, for closed issues, and for commits on the main branch, which is the correct branch name. And the last one is not about the project at all: it is a deploy status badge for the documentation site, hosted on a static hosting platform under a different account name.

So the project's own health badges and its documentation deploy status sit in the same row, which is a small presentational muddle rather than anything substantive.

## A backup configuration file is committed next to the live one

The root listing has a pattern worth naming, because it is a habit rather than an accident.

There is a configuration file listing the translation endpoints, and immediately beside it a file whose name is the same with a backup suffix. Both are committed.

That is what happens when somebody edits a list of dozens of third party endpoints by hand, breaks something, and commits a copy of the previous state rather than using version control. Since the live file is tracked, the backup adds nothing except a second file for a reader to puzzle over and for the next person to edit instead of the real one.

The same habit shows up elsewhere in the tree, in a directory whose name is a donation platform plus the word service, sitting at the repository root with spaces in it rather than under a documentation or static folder.

None of this affects the extension's behaviour. It does mean the repository's shape carries some traces of how it was worked on rather than how it is designed, which is the usual state of an actively used personal project and a fair signal that the unmaintained notice is not a stylistic choice.

## The prompt database ships in the repository, and the docs live on another host

Two structural decisions explain how this extension is delivered.

The first is that its data is in the tree. There are directories for prompt tags, for grouped tags, and for models, alongside a translations file and a set of style files and a style sheet at the root. So the prompt vocabulary ships with the extension rather than being fetched on first run.

That is a deliberate trade. It means the extension works offline for browsing and organising prompts, and it means the repository carries data that could equally have been a downloadable index.

The second is that the documentation is elsewhere. The readme contains no installation instructions at all. It links to a hosted documentation site with separate pages for installation, extension updates, translation configuration, contributing, a custom theme section, and frequently asked questions, plus a donation link.

So the two things a new user needs, how to install it and how to configure translation, are both one click away and neither is in the repository. For a project whose maintenance statement is a farewell, that matters: the wiki is where the knowledge lives, and the wiki is not archived with the code.

## Conclusion

This suits someone who wants a better prompt editor than a pair of plain text areas and who is willing to treat translation as a best effort service rather than a dependency. It does not suit anyone building on it long term, because the author says it will not be maintained and says pull requests will be merged when there is time. Before you install, check three things: which translation tier you are willing to use, because the tier that needs no key is documented as unstable and explicitly not bug reportable; whether your prompt text can leave your machine, which is what the automatic translation feature does by default; and whether the standalone application suits you better, since the author recommends it and it does not depend on the web interface at all.

## FAQ

### What is Physton/sd-webui-prompt-all-in-one?

An MIT licensed browser extension for the stable-diffusion web interface that replaces the plain prompt and negative prompt text areas. It adds bilingual prompt comparison for readability, automatic translation using dozens of online services plus offline models, history that records changes to the prompt fields, favourites with batch bookmarking, and drag-and-drop reordering with one-click weight increase and decrease. The prompt vocabulary itself ships in the repository as tag and group directories.

### Is Physton/sd-webui-prompt-all-in-one still maintained?

The author says otherwise in bold in the readme: the project will no longer be maintained because of limited personal energy, while inviting pull requests and saying they will be merged into the main branch when there is time. The repository is not archived and the branch was last pushed on 2026-09-13. The same readme points readers to a separate standalone application that runs without the web interface.

### Does sd-webui-prompt-all-in-one send my prompt text to a translation service?

It can, and the readme describes three tiers. The tier that needs no key is documented as highly unstable, with the note that not every such service works on your machine, that you should switch to another if it fails, and that you should not open an issue about it. A second tier needs a key you apply for yourself, and the readme says most are free. A third tier translates offline and downloads language models automatically at initialisation.

### How do I install sd-webui-prompt-all-in-one?

The readme contains no installation steps. It points at a hosted documentation site with separate pages for installation, extension updates, translation configuration, contributing, a custom theme section and frequently asked questions, plus a donation link. That site is deployed as a static site under a different account, and the readme's own deploy badge points at it.

## Sources

- [Issues](https://github.com/Physton/sd-webui-prompt-all-in-one/issues)
- [License: MIT](https://github.com/Physton/sd-webui-prompt-all-in-one/blob/main/LICENSE)
- [Physton/sd-webui-prompt-all-in-one on GitHub](https://github.com/Physton/sd-webui-prompt-all-in-one)
- [Project website](https://aiodoc.physton.com)
- [README](https://github.com/Physton/sd-webui-prompt-all-in-one/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/physton-sd-webui-prompt-all-in-one
