WordPress/ai

What problem does this address? At the moment, we have a fairly small hardcoded list of languages you can choose from when using the Content Translation experiment. This list is passed through a filter (wpai_content_translation_languages) allowing others to extend that list as needed. Opening this Issue to raise discussion on if that approach is good enough and we leave the list as-is or if there are languages missing from this list that we should always support by default. What is your proposed solution? Look to add additional languages to our get_supported_languages method. As mentioned above, we may end up deciding the languages we have there are already good enough and anyone wanting different languages can utilize the wpai_content_translation_languages filter. Why is this important to you? No response I have searched existing issues and this is not a duplicate. Yes

What problem does this address? Most of our other experiments will integrate into the WordPress Guidelines/Knowledge that currently ships with the Gutenberg plugin. This allows you to set site-wide and block-specific guidelines that if found, we pass those guidelines to the LLM when generating a request. Content Translation (shipped in #747) doesn't do this though would be helpful for things like providing a glossary of words and how they should be translated or other copy things to keep in mind when doing the translation. What is your proposed solution? Enhance the Content Translation Ability to declare support for guidelines using the guideline_categories method. Likely start with Site, Copy and Additional as our categories. Worth noting the Guidelines experiment in Gutenberg has changed names a few times and our integration isn't currently working due to another naming change. This will need fixed first (or alongside) the changes needed here. Why is this important to you? No respons

Description has_valid_ai_credentials() decides whether any configured connector is valid by asking a single question: can it generate text? A site whose only connector is a speech or image provider is therefore told its connectors may be invalid, when they are correctly configured and working. The notice shown is: The AI plugin requires a valid AI Connector to function properly. Please review the AI Connectors you have configured to ensure they are valid. That reads as "your connector is broken." The connector is fine; it simply does not do text. Expected: the plugin explains that its features need a text-generation connector, and that the configured connector does not provide one. Actual: a red error notice asking the user to review their connectors "to ensure they are valid." Note the UI already distinguishes two cases — "no connectors configured" versus "configured but not valid" — and a non-text connector lands in the second. So the connector is detected correctly; it is the

What problem does this address? Authors and editors often lack full context of everything already published on a site, so valuable opportunities to link new posts to related existing content go unused. Internal links are one of the higher-leverage, lower-effort levers for on-site engagement and SEO (they pass link equity, surface related content to readers, and help establish topical authority), but finding good linking opportunities by hand doesn't scale, especially on larger sites. What is your proposed solution? Add a new experiment that suggests up to 5 (filterable) internal links per post, pointing to other existing content on the same site. Links are suggested only, never auto-inserted so that the author/editor reviews and accepts/rejects each one, consistent with how every other experiment in this plugin requires explicit user action. I considered a "related posts" block/widget at the end of a post as an alternative, but this would have lower engagement than in-content context

What problem does this address? Markdown output can make content easier for AI tools, agents, search/indexing workflows, static exports, and reader experiences that prefer structured plaintext. The prior implementation in #194 explored much of the product surface, including Markdown feed output, singular Markdown views, autodiscovery links, Accept: text/markdown support, settings toggles, filters, and tests. This new experiment should revisit that direction with https://github.com/dmsnell/html-to-md as the conversion layer rather than maintaining a separate converter. What is your proposed solution? Create a new Markdown Feeds experiment that exposes content as Markdown, building on the prior work in #194 and using https://github.com/dmsnell/html-to-md for HTML-to-Markdown conversion. Potential scope to consider: Add a new Markdown Feeds experiment, disabled by default Provide Markdown output for feed requests Support Markdown output for singular content Prefer ?format=md as the prim