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

Translation mechanism requires translators to be programmers #2033

Closed
benwerd opened this Issue Feb 26, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@benwerd
Member

benwerd commented Feb 26, 2018

Caveat: I created the original Language object, and I can't remember what my intentions were.

Right now, any translator of Known has to actually write a plugin to make a language available. It's possible that translators are also programmers, but it's not necessarily true.

Known needs a standard way to extract all GetText strings, make them available as a corpus for translation using standard tools, and have pure language files be automatically available.

Without these things, it's almost impossible to translate Known in an efficient way using tools familiar to most open source translators.

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Feb 26, 2018

Collaborator

Not quite true.

What you're describing already exists, and is one of the reasons why I added gettext support in addition to the MAoS support (which absolutely definitely does require translators to be programmers, and was one of its biggest problems).

So, at the moment, the priority is add the translation hooks around strings. The next step is that we generate this corpus, using a script I've already written (see /languages), which generates a .POT file by analysing the text and pulling strings out from these hooks. This is the primary way, but there's also a debug hook that's triggered when a string with no translation is used.

This file needs to only be generated when strings are added or changed, but largely this will be static, and only really needs to be done by us. We distribute this with Known, and can be loaded into any number of existing tools, including web based ones.

Collaborator

mapkyca commented Feb 26, 2018

Not quite true.

What you're describing already exists, and is one of the reasons why I added gettext support in addition to the MAoS support (which absolutely definitely does require translators to be programmers, and was one of its biggest problems).

So, at the moment, the priority is add the translation hooks around strings. The next step is that we generate this corpus, using a script I've already written (see /languages), which generates a .POT file by analysing the text and pulling strings out from these hooks. This is the primary way, but there's also a debug hook that's triggered when a string with no translation is used.

This file needs to only be generated when strings are added or changed, but largely this will be static, and only really needs to be done by us. We distribute this with Known, and can be loaded into any number of existing tools, including web based ones.

@mapkyca mapkyca closed this Feb 26, 2018

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Feb 26, 2018

Collaborator

I'm in favour of keeping the MAoS support as it currently stands, as it allows one-man-band plugin authors (who are programmers) a quick way of being compliant, without needing to read up on gettext - which might be a little onerous, especially if you've only a couple of strings.

However, as I've written it, it can largely be used interchangeably, and conversion to a gettext corpus can be done largely automatically.

Collaborator

mapkyca commented Feb 26, 2018

I'm in favour of keeping the MAoS support as it currently stands, as it allows one-man-band plugin authors (who are programmers) a quick way of being compliant, without needing to read up on gettext - which might be a little onerous, especially if you've only a couple of strings.

However, as I've written it, it can largely be used interchangeably, and conversion to a gettext corpus can be done largely automatically.

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Feb 26, 2018

Collaborator

Here's a bit of a summary: https://www.marcus-povey.co.uk/2018/02/22/gettext-support-in-known/ also on docs.withknown.com

Collaborator

mapkyca commented Feb 26, 2018

Here's a bit of a summary: https://www.marcus-povey.co.uk/2018/02/22/gettext-support-in-known/ also on docs.withknown.com

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Feb 26, 2018

Collaborator

Latest build demonstrates how to apply per-plugin translations.

If you look at the Status plugin now, you'll see that (for all the hooks I've added so far) all the actual programming has been done, and it can now be translated.

Collaborator

mapkyca commented Feb 26, 2018

Latest build demonstrates how to apply per-plugin translations.

If you look at the Status plugin now, you'll see that (for all the hooks I've added so far) all the actual programming has been done, and it can now be translated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment