Move Translation Propagation into a plugin #337
Assignees
Labels
[Priority] Blocker
[Status] In Progress
Tracking issues with work in progress
[Type] Bug
An existing feature is broken.
Milestone
Comments
|
I'm not sure this is really a bug, but I agree it should be moved out to a plugin, if possible. I don't know if that's possible for 1.1 or not though. Could we disable it for 1.1 and look to remove it in 1.2? That way if an install is using it in 1.0 they could re-enable it with a define in 1.1. |
ocean90
added a commit
that referenced
this issue
Mar 16, 2016
Translation propagation/matching in its current state has a few issues: * Wrong translations can be automatically validated, see https://meta.trac.wordpress.org/ticket/1411. * There is no difference between nouns and verbs, see also https://wordpress.slack.com/archives/polyglots/p1457105584001087. * It doesn't scale: On translate.w.org an import with enabled matching for one original for ~100 translation sets takes ~3 seconds. For 50 originals that would be 2.5 minutes. * On systems with more than one database the propagation can lead to duplicates. That's why it's currently disabled on translate.w.org. The PR removes the functionality from core so it can be moved into a separate plugin which allows us to enhance it further, apart from the release cycle of the GlotPress plugin. See #337.
ocean90
added
[Status] In Progress
ocean90
added a commit
that referenced
this issue
Mar 17, 2016
Translation propagation/matching in its current state has a few issues: * Wrong translations can be automatically validated, see https://meta.trac.wordpress.org/ticket/1411. * There is no difference between nouns and verbs, see also https://wordpress.slack.com/archives/polyglots/p1457105584001087. * It doesn't scale: On translate.w.org an import with enabled matching for one original for ~100 translation sets takes ~3 seconds. For 50 originals that would be 2.5 minutes. * On systems with more than one database the propagation can lead to duplicates. That's why it's currently disabled on translate.w.org. The PR removes the functionality from core so it can be moved into a separate plugin which allows us to enhance it further, apart from the release cycle of the GlotPress plugin. See #337.
|
Plugin has its own repo: https://github.com/GlotPress/gp-translation-propagation |
|
Plugin submitted to the w.org repo on 2016-3-26. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Cross project translations matching was proposed in https://glotpress.trac.wordpress.org/ticket/327 and implemented via 1034, 1095, 1097, 1126, 1128, 1144, 1176, 1177, and 1178.
It started as an alternative for the Translation Memory and isn't yet finalized – it probably shouldn't be included in v1.0 of the plugin at all.
Some of the recent commits are more or less tied to the workflow on translate.w.org which is usually a bad idea because GlotPress is used by a few more platforms.
Translations matching in its current state has a few issues:
I'm proposing to move Translation Propagation into a plugin which would still be maintained by us but can benefit of a separate release cycle. It should be marked as a feature plugin which would allow us to perform potential breaking changes.
This step would also be future-proof: When the real Translation Memory gets developed (which should probably start as a feature plugin as well) it's unlikely that both systems would run at the same time.
ToDo:
The text was updated successfully, but these errors were encountered: