Skip to content

Import the local pages as GlotPress' projects #1856

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 25 commits into
base: local
Choose a base branch
from

Conversation

amieiro
Copy link
Member

@amieiro amieiro commented Aug 15, 2024

Problem

The WordPress.org projects needs to be able to translate the documentation from English to another languages. We have had a few meetings (WCEU 2023, WCEU 2024) and we want to test GlotPress as the translation engine.

Solution

This PR is a first step, doing these steps:

  • Add a list of pages in the GlotPress backend, so the GTE will be able to import to GlotPress with a button.
  • Import the pages into GlotPress, splitting each block as an original string.
  • Export the translated content into a new page.

Screenshots or screencast

Local GlotPress

image

Original page

image

Translation page in GlotPress

image

Translated page

image

@adamziel
Copy link

adamziel commented Sep 9, 2024

Thinking about using Playground for editing WordPress Documentation, one of the possible data flows is importing markdown documentation files from a GitHub repository into Playground, making edits, and then creating a Pull Request directly from Playground.

I wonder how we could make the two workflows compatible, so enable translating documentation pages brought over from markdown files from GitHub. We have a two-way markdown<->blocks conversion pipeline at https://github.com/dmsnell/blocky-formats so we can reason about blocks instead of text paragraphs. Would that suffice? Or would we have store some additional structured data in the repo to cross-reference paragraphs/blocks from different markdown files?

@akirk
Copy link
Member

akirk commented Sep 30, 2024

@amieiro and I discussed that the current implementation on writing <data> tags to block HTML currently breaks editing the translated blocks as they are all flagged for invalidity.

Possible solution: add the metadata to the block attribute json (for example as fake css class names so that they remain after editing the page gp-original-123) and convert it to a element upon output by getting the data from the database. A positive aspect of this is that we can do this transformation only for people with permission (= logged in users).

@adamziel
Copy link

adamziel commented Sep 30, 2024

Would the meta attribute work? Or storing it as a block binding?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants