AumLang turns your WordPress site multilingual with one-click AI translation that keeps your page builder layouts intact. It uses the AI client that ships with WordPress 7.0, so on a site that already has a provider connected there is nothing to configure and no key to enter.<\/p>\n\n
Highlights<\/strong><\/p>\n\n Either way the AI account is yours, so translation cost is under your control \u2014 no per-translation fees, no quotas from us, and no account with us of any kind.<\/p>\n\n AumLang prefers the AI client that ships with WordPress 7.0, and new installs use it by default. The site owner connects a provider once under Settings > Connectors<\/strong>; this plugin then sends only the text to be translated, holds no API key of its own, and shares that one connection with every other plugin on the site.<\/p>\n\n A direct connection is also offered, because the connectors WordPress ships cover Anthropic, Google and OpenAI, and a site whose network cannot reach any of those still needs a way to translate. It is entirely opt-in and requires your own key.<\/p>\n\n Nothing leaves your site until you pick an engine and start a translation. The plugin has no account with us, sends no telemetry, and makes no request on its own.<\/p>\n\n Using the WordPress AI Client:<\/em> the text being translated goes to whichever provider the site owner connected under Settings > Connectors. WordPress owns that connection and its credentials; the terms that apply are those of the provider chosen there.<\/p>\n\n Using the direct connection:<\/em> the plugin is a client for the OpenAI-compatible chat API, so it can talk to any service implementing it. It sends the strings being translated together with the source and target language, and nothing else. You supply the endpoint, the model and the key; presets are offered purely to fill the endpoint and model fields for services people commonly use:<\/p>\n\n Choosing a preset changes two text fields; it does not contact anything. Any other compatible endpoint can be entered by hand, in which case its operator's terms are the ones that apply.<\/p>\n\n Text that has already been translated is served from your own database and never leaves the site again.<\/p>\n\n This plugin bundles flag-icons<\/strong> 7.2.3 by Panayiotis Lipiridis, unmodified, as the flag images in\n src\/assets\/flags\/. It is licensed MIT; the licence text ships alongside them in\n src\/assets\/flags\/LICENSE.txt.<\/p>\n\n The plugin makes no requests to any external service<\/strong> to render a switcher: the flags are served\nfrom this plugin's own directory.<\/p>\n\n\n Not if WordPress already has one. AumLang's default engine is the AI client built into WordPress 7.0, which uses the provider connected under Settings > Connectors \u2014 that connection belongs to WordPress, is shared with every other plugin, and this plugin never sees the key.<\/p>\n\n You need your own key only for the second engine, the direct connection. It exists because the connectors WordPress ships cover Anthropic, Google and OpenAI, and a site whose network cannot reach any of those still needs a way to translate. It speaks the OpenAI-compatible chat API, so any service implementing it will do; you supply the endpoint, the model and the key, and the AI account is yours either way.<\/p><\/dd>\n Yes. AumLang reads each builder's own structure, translating only the text and leaving layout, styles and design untouched \u2014 including custom widgets.<\/p><\/dd>\n Yes \u2014 product title, description, short description, categories, tags, brands and attributes, while carrying over price, stock and gallery so the translation remains a complete product. Multi-currency is intentionally out of scope; pair AumLang with a dedicated currency plugin if you need it.<\/p><\/dd>\n Add the language switcher via the \n
Translation engines<\/h4>\n\n
External Services<\/h4>\n\n
\n
External and bundled resources<\/h3>\n\n
\n
\n
aumlang<\/code> folder to \/wp-content\/plugins\/<\/code>, or install the plugin ZIP via Plugins \u2192 Add New \u2192 Upload.<\/li>\n\/zh\/<\/code> require them.<\/li>\n\n
Do I need an API key?<\/h3><\/dt>\n
Does it work with Elementor and Gutenberg?<\/h3><\/dt>\n
Will it translate WooCommerce products?<\/h3><\/dt>\n
How do visitors switch language?<\/h3><\/dt>\n
[aumlang_language_switcher]<\/code> shortcode, the block, the widget, or the aumlang_language_switcher()<\/code> template tag.<\/p><\/dd>\n\n<\/dl>\n\n\n1.0.10<\/h4>\n\n
\n
1.0.9<\/h4>\n\n
\n
Acf<\/code> to AcfFields<\/code>, so a file called Acf.php<\/code> can no longer be read as a bundled copy of Advanced Custom Fields. No behaviour changes: the class has always been ours, and it still does nothing unless ACF is active.<\/li>\n<\/ul>\n\n1.0.8<\/h4>\n\n
\n
1.0.7<\/h4>\n\n
\n
shutdown<\/code> instead of being left for PHP to flush at the end of the request. Nothing about discovery changes; the buffer stack the plugin hands back is now the one it was given.<\/li>\n<\/ul>\n\n1.0.6<\/h4>\n\n
\n
en<\/code> is neither the British nor the American flag, but en_GB<\/code> and en_US<\/code> are. A language registered without a country simply shows no flag rather than a guessed one.<\/li>\naria-hidden<\/code> and the language name is still announced, because a flag is a country and not a language. New aumlang_flag_html<\/code> filter for sites that want to supply their own images.<\/li>\naumlang_render_floating_switcher<\/code> filter so a theme that places the switcher itself can stand the floating one aside. Without it the two are fixed to the same corner and overlap.<\/li>\n<\/ul>\n\n1.0.5<\/h4>\n\n
\n
1.0.4<\/h4>\n\n
\n
rel=canonical<\/code> and body_class()<\/code> still described the source post \u2014 the body was in one language and the <title><\/code> in another, and the canonical told search engines the translation was a duplicate of the original. Anything reading the queried object, including every SEO plugin, was affected.<\/li>\n<\/ul>\n\n1.0.3<\/h4>\n\n
\n
aumlang_translate_meta_value<\/code> filter to override per key.<\/li>\n<\/ul>\n\n1.0.2<\/h4>\n\n
\n
\/{lang}\/<\/code> and \/{lang}\/{page}\/<\/code> worked, which is why this was easy to miss.<\/li>\n\/{lang}\/<\/code> was answered with a 301 to the unprefixed home page, so the translated front page could not be reached. Core's canonical redirect now stands aside for language-prefixed URLs only.<\/li>\n<\/ul>\n\n1.0.1<\/h4>\n\n
\n
aumlang_register_parsers<\/code> action so other plugins can add a content parser. A builder that stores its layout outside post_content<\/code> is invisible to the built-in parsers and translates as an empty page; this is the supported way to teach AumLang about one.<\/li>\n1.0.0<\/h4>\n\n
\n