How do their APIs compare?

These are two very differently-shaped "APIs," and even the retrieval above illustrates that: one is a rich desktop-app plugin/UI SDK, the other is a lightweight, provider-oriented plugin contract for a translation utility. Here's the comparison based on what's visible in the repository data:

devtoys-app/devtoys: DevToys.Api

DevToys exposes a proper extension SDK (src/app/dev/DevToys.Api, described in its own README as "SDK for building an extension for DevToys" [src/app/dev/DevToys.Api/README.md:L1-L3]). Key characteristics:

• Tool contract via MEF-style export attributes. Built-in and third-party tools implement IGuiTool and are discovered through [Export(typeof(IGuiTool))], decorated with metadata attributes like [Name(...)], [ToolDisplayInformation(...)], [MenuPlacement(...)], [Order(...)], and [TargetPlatform(...)]. This is visible in the Extensions Manager tool itself, which is implemented as an IGuiTool [src/app/dev/DevToys.Blazor/BuiltInTools/ExtensionsManager/ExtensionsManagerGuiTool.cs:L1-L69].
• Declarative UI construction — tools build a UIToolView using a fluent/builder-style API (e.g., InfoBar(...), List(...)) rather than raw markup, as seen in ExtensionsManagerGuiTool's _restartRequiredInfoBar and _extensionList fields [src/app/dev/DevToys.Blazor/BuiltInTools/ExtensionsManager/ExtensionsManagerGuiTool.cs:L48-L50].
• Dependency injection via [Import] for services like IFileStorage, IWebClientService, ISettingsProvider [src/app/dev/DevToys.Blazor/BuiltInTools/ExtensionsManager/ExtensionsManagerGuiTool.cs:L54-L60].
• Settings API — SettingDefinition<T> provides typed, named settings with value-based equality/hash code overrides and operator overloads (==/!=) [src/app/dev/DevToys.Api/Settings/SettingDefinition.cs:L89-L125].
• Supporting abstractions for file/stream I/O agnostic of whether input is a path or FileInfo, via OneOf<string, FileInfo> extension methods like GetStreamAsync/ReadAllTextAsync [src/app/dev/DevToys.Api/Core/OneOfExtensions.cs:L8-L117], plus platform services like IFontProvider.GetFontFamilies() [src/app/dev/DevToys.Api/Core/IFontProvider.cs:L6-L13].
• Blazor UI component layer underneath the tool API (e.g., RadioButton, ToggleSwitch, DropDownListItem) that the GUI toolkit is built on [src/app/dev/DevToys.Blazor/Components/BasicInput/RadioButton/RadioButton.razor.cs:L1-L28] [src/app/dev/DevToys.Blazor/Components/BasicInput/ToggleSwitch/ToggleSwitch.razor.cs:L1-L22].
• JS interop bridge for Monaco Editor — TypeScript/JS classes like MonacoEditorLanguage register custom languages, auto-completion, and semantic tokenization providers that call back into .NET via dotNetObjRef.invokeMethodAsync [src/app/dev/DevToys.Blazor/Assets/javascript/monacoEditorLanguage.ts:L4-L43], [src/app/dev/DevToys.Blazor/Assets/javascript/monacoEditorLanguage.js:L12-L60]. This is also reflected in the import graph, where monacoEditor.ts is the most-depended-on file (4 importers) per RepoPilot's architecture signal.

So DevToys' API is essentially a UI+lifecycle extension model: extensions declare a tool, contribute UI, consume DI services, and optionally hook into the editor's language services.

stranslate/stranslate: plugin architecture

Stranslate's pl