- Parse headings and descriptions of items into strings (format depends on T276708))
- Export to translatewiki.net
- Import translated strings (cronjob etc) from translatewiki.net into repo
- Deploy repo, see T290257: Workflow how to deploy changes for that
Description
Description
Event Timeline
Comment Actions
#translatewiki chat
[18:59] < bd808> semi-random question: I have been asked to look into multi-lingual static site generation and was wondering if there are any known TWN projects that might be doing something like that. Mostly I guess I'm wondering if there are any custom import/export scripts that have been written to take something like a markdown document and load it into TWN as multiple translation units. [19:00] < bd808> I think I'm envisioning something a bit like Extension:Translate but all static and external to MediaWiki. [19:40] <Nikerabbit> bd808: doesn't ring a bell immediately [19:41] <Nikerabbit> I guess you would just need to file format handler for markdown for splitting it into units and some logic to generate the multilingual site [19:44] < bd808> yeah, I was guessing that should be technically possible. The markdown or whatever might need some extension markup to split into reasonable translation units. [19:46] < bd808> But for know just knowing that it is a semi-novel problem to solve is what I needed. :) Thanks Nikerabbit [19:47] <Nikerabbit> I think that if one would spend effort digging, one would find prior art [19:48] <Nikerabbit> if you're willing to compromise with markup not being the source format, it would be rather trivial [19:49] <Nikerabbit> I'm not so familar with markdown to say what would make sense as syntax for marking things (not) translatable [19:50] <Nikerabbit> but I think from twn side we could pretty easily handle the fuzzy-matching of changed units based on content, so you wouldn't need explicit identifiers [19:50] <Nikerabbit> (kinda similar to Gettext) [19:51] <Nikerabbit> quick googling finds https://www.npmjs.com/package/gettext-markdown and https://stackoverflow.com/questions/8036168/translating-longer-texts-view-and-email-templates-with-gettext [19:52] <Nikerabbit> but of course devil is in the details and in the quality and control/flexibility of managing the splitting process
Comment Actions
Pasting some more notes from conversations with Bryan (so this is all Bryan's knowledge, not mine), in addition to the conversation above:
- Translation setup will need building something that we don't have.
- When using a library for GNU gettext, twn can already deal with it
- High-level workflow:
- Source of truth docs (YAML, Markdown, etc), largely dictated by generator of site content (e.g. static)
- parse strings
- to pull Gerrit repo regularly
- pick .po files to merge
- generating pages in languages, likely compile into Docker container, once a week deployment window (translations, content to push to site)
- trigger deployments (human being vs automated)
- (Toolhub comparison: Django uses gettext po files, wired into twn, so that's basically only setting up configuration.)
- (Toolhub = Translation applied at runtime. Versus purely static with nothing on backend and only Apache content module/nginx checking HTTP accept header)
- Regarding Vuepress (node based static site generator; only one potential candidate; which was used for T286082), some info for folks who would manually add translated strings) is at https://vuepress.vuejs.org/guide/i18n.html#site-level-i18n-config (looked up by Bryan)
Comment Actions
(If we ever ended up with a more complex tag/category system, displaying all translated items can create some confusion (T273550))
Comment Actions
Python lib for Markdown translation via PO files: https://mdpo.readthedocs.io/en/master/index.html
Comment Actions
I do! :) Some of the bits mentioned in the description are still work in progress, but they are tracked independently.