Where the site's data comes from

This site is generated from the Xendroid+ repository, in two languages: English at the root of the address and Portuguese under pt-br/. Every page exists in both, with the same content, and the language switch in the header leads to the same page in the other language. What can be read from the code is read from the code on every build; what needs explaining is written by hand, in Markdown, and checked against the code when possible. Nothing guarantees that hand-written text stays correct after the app changes: that is why each page says which version it was reviewed against and warns you when the code it cites has changed since then.

Two versions #

• Stable: the commit of the latest release published on GitHub, currently build 63 (732c64db). It is the version the home page offers for download and the basis for the documentation and the simulator.
• Development: the main commit the site is generated from (87b5c00f).

The build reads the two separately: the stable version in a worktree of its own, at the release commit. When both give the same data (main only changed the site, a workflow or code comments), the site shows a single version and says so. When the data changed, the settings reference lists the differences, documentation passages marked with a version say from which build they apply, and the data of both is published in dados/estavel.json and dados/desenvolvimento.json.

What is read from the code #

The setting texts are the app's own: English pages show the app's English strings (app/src/main/res/values/), and Portuguese pages, under pt-br/, show its Brazilian Portuguese strings (app/src/main/res/values-pt-rBR/); when the app has no translation, the text appears in English, marked as such. Release summaries come from each release's update-summary:en block on English pages and from its update-summary:pt-BR block on Portuguese pages, and the performance table comes from README.md on English pages and from README.pt-BR.md on Portuguese pages. The Xenia title database bundled with the core is used only to give a Title ID a name: its compatibility status is for Xenia on PC and does not apply to Xendroid+.

What is written by hand #

• The documentation pages, in website/content/docs/en/*.md (English) and website/content/docs/*.md (Portuguese).
• The home page texts and the screenshot captions, in website/scripts/site/landing.mjs, website/content/prints.mjs and website/content/prints.en.mjs.
• The simulator's annotations and example data (games, sessions, profiles), marked as examples in the tool itself. The simulator is written in Portuguese; the build generates the English version by replacing each text with the one in the website/content/simulador.en.json dictionary, or with the app's own English text when it is the same label as in the app, and stops if any text lacks a translation.

Each documentation page states in its front matter the commit it was reviewed against (conferido) and lists the app files it describes (fontes). If any of those files changed between the review and the stable version, the page shows a warning at the top and the build records the case. Values such as the version, the APK size, the package and the counts enter the pages by reference to the data ({{estavel.build}}, for example), not written into the text.

What the build checks #

On every build, the site checks:

• that each app setting has a cvar in the core, in the same section, and that the values the app writes are of a type the core accepts;
• that the keys of the default_config.toml template exist in the core;
• that the automatic per-game fixes point to cvars that exist;
• that each patch file has the same Title ID as its file name;
• that every internal link, anchor, cited repository file, screenshot and simulator screen exists;
• that every page has its version in the other language and that the two point to each other.

A problem that makes the site wrong (data that could not be read, a broken link) stops publishing. An inconsistency in the app itself does not stop the site: it goes into the list below, which is a snapshot of the code of build 63.

Warnings about the code (17)

• Vulkan|vulkan_validation = "false": a cvar é int32 e o valor seria boolean · app/src/main/java/xendroid/compose/settings/SettingsSchema.kt:20
• Vulkan|vulkan_validation = "true": a cvar é int32 e o valor seria boolean · app/src/main/java/xendroid/compose/settings/SettingsSchema.kt:20
• Kernel|stack_size_multiplier_hack: o core não define a cvar "stack_size_multiplier_hack"; o valor gravado é ignorado · app/src/main/java/xendroid/compose/settings/SettingsSchema.kt:105
• emulator-core/src/main/assets/config/default_config.toml [CPU] disable_global_lock: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [CPU] disable_global_lock
• emulator-core/src/main/assets/config/default_config.toml [GPU] gamma_render_target_as_srgb: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [GPU] gamma_render_target_as_srgb
• emulator-core/src/main/assets/config/default_config.toml [GPU] query_occlusion_sample_lower_threshold: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [GPU] query_occlusion_sample_lower_threshold
• emulator-core/src/main/assets/config/default_config.toml [GPU] query_occlusion_sample_upper_threshold: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [GPU] query_occlusion_sample_upper_threshold
• emulator-core/src/main/assets/config/default_config.toml [GPU] readback_memexport: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [GPU] readback_memexport
• emulator-core/src/main/assets/config/default_config.toml [General] notification_sound_path: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [General] notification_sound_path
• emulator-core/src/main/assets/config/default_config.toml [Kernel] Allow_nui_initialization: o core não define essa cvar · emulator-core/src/main/assets/config/default_config.toml [Kernel] Allow_nui_initialization
• emulator-core/src/main/assets/config/default_config.toml [Vulkan] vulkan_validation = false: a cvar é int32 e o valor seria boolean · emulator-core/src/main/assets/config/default_config.toml [Vulkan] vulkan_validation
• [desenvolvimento] 464507E1 - Farming Simulator (TU1).patch.toml: title_id 464507DC difere do nome do arquivo
• [desenvolvimento] 464507E1 - Farming Simulator.patch.toml: title_id 464507DC difere do nome do arquivo
• [desenvolvimento] 534507D4 - Syndicate.patch.toml: title_id 45410923 difere do nome do arquivo
• [estavel] 464507E1 - Farming Simulator (TU1).patch.toml: title_id 464507DC difere do nome do arquivo
• [estavel] 464507E1 - Farming Simulator.patch.toml: title_id 464507DC difere do nome do arquivo
• [estavel] 534507D4 - Syndicate.patch.toml: title_id 45410923 difere do nome do arquivo

App defaults that differ from the core (12)

The app writes its own value on the first launch (the one in the default_config.toml template, or the schema’s when the template lacks the key); the core would only use its own default if the key were missing from the file.

Publishing #

The site is published to GitHub Pages by the .github/workflows/pages.yml workflow, which runs:

• on every push to main that changes the site or a file it reads: the app, the core, the patches, the READMEs and the documents;
• when the APK workflow finishes successfully on main, which covers new releases (releases created by the CI itself do not trigger other workflows);
• once a day, to pick up releases published or edited by hand;
• on demand, from the Actions tab.

In a pull request, the workflow only builds and checks the site, without publishing it. The GitHub Actions token is used only during the build, to read the releases; it never reaches the pages.

Maintaining the site #

• Build and view locally: in website/, run npm ci, npm run build and npm run serve, which serves the site at the same path as GitHub Pages.
• Check: npm run check looks for broken links and resources; npm test runs the browser tests (layout, keyboard, search, simulator).
• A new page is two Markdown files, one in website/content/docs/en/ (English) and one in website/content/docs/ (Portuguese), with title, description, section and order in their front matter; the English one also has pt: <Portuguese file name>, which pairs the two.
• After reviewing a page against the current code, update its conferido.

The full maintenance guide is in the site README.