Apply a Japanese house style to WordPress posts with Gemini and Slack

Quick overview

This workflow checks WordPress posts for Japanese spelling variants using a glossary and rules, asks Google Gemini to judge context-dependent replacements, and sends a Slack approval form to apply selected changes and optionally expand the glossary.

How it works

1. Runs every morning on a schedule, or starts on demand from an n8n form (or a sub-workflow call) with a specific WordPress post ID.
2. If no post ID is provided, queries the WordPress REST API for recently modified published posts and processes each post in its own independent execution.
3. Fetches the target post content from WordPress, loads glossary terms and past per-post decisions from n8n Data Tables, and scans only plain text (excluding tags, block comments, code-like blocks, and URLs) for glossary variants, width variants, and katakana long-vowel inconsistencies.
4. Sends context-dependent occurrences (for example 事/こと or 時/とき) to Google Gemini with the house-style rule and parses the per-occurrence replace/keep judgements.
5. Builds grouped replacement proposals and posts them to Slack as an interactive form for an editor to choose what to fix and which new katakana pairs to add to the glossary.
6. Applies only the editor-selected replacements, re-fetches the post to avoid overwriting concurrent edits, updates the post in WordPress when unchanged, and posts the outcome back to Slack.
7. Records applied/rejected proposals to a decisions Data Table so rejected items are not suggested again for the same post, and adds any approved new pairs to the glossary Data Table.

Setup

1. Add WordPress HTTP Basic Auth credentials (for example an application password) and set the correct site URL and post type in the workflow configuration values.
2. Create n8n Data Tables named glossary_terms (preferred, variants, kind, note) and term_decisions (post_id, variant, preferred, decision, count, decided_at) and ensure the column names match what the workflow writes.
3. Add Google Gemini credentials for the LangChain Google Gemini chat model node.
4. Add Slack credentials, invite the Slack app to your target workspace/channel, and set the channel ID in the Slack nodes that send the proposal, no-variant report, edit-conflict warning, and confirmation.
5. If using the form trigger, open the form once to copy its URL and share it with editors who should submit a WordPress post ID for review.
6. Set the workflow time zone to your site's time zone so the morning run and the "changed in the last hours" window match your posts.

Requirements

• WordPress with the REST API and an application password for a user who can edit posts
• Google Gemini API key
• Slack app with chat:write
• n8n Data Tables

Customization

• Add your house style to glossary_terms. Separate several variants with 、. Use fixed for spellings code can always replace, and context with a short rule in note for spellings that depend on meaning.
• Turn off use_default_glossary in Config to rely only on your own glossary. Your rows always win over the starter list.
• Adjust max_proposals, max_context_checks, lookback_hours and the full-width / half-width rules in Config.

Additional info

Tested end to end on a local WordPress site with Japanese posts:

• Only ticked spellings were replaced; link URLs, code blocks and block comments stayed untouched.
• 事業, 出来事 and 資料を下さい were left as they are, while 〜する事, 出来る and ご確認下さい were proposed. 見積もり時 (read as じ) is kept as kanji.
• A second run did not repeat rejected proposals.
• A katakana pair added from Slack was used as a glossary term on another post the next run.
• When Gemini returned a 503, the code-only proposals still reached Slack.
• When the post was edited while the approval was open, nothing was written and Slack explained why.