Double posting, because this post is very different from my above one. This is because I've finally gotten around with playing with the Extension:TL. Here's my feedback.
First of all,
this privilege needs to be made available to some more groups. If it isn't, no one's able to mark new sections or revisions for translation. The only thing regular users can do right now is actually "translate" the Test page TLG set up. We can't define more sections. Even if we edit the raw, it won't show up on the translate interface unless someone marks the page for translation. Here's the privilege:
Code: Select all
Mark versions of pages for translation (pagetranslation)
.
Someone
please please please change that privilege. @______@ It's currently restricted to Administrators, and with it set, I can't perform tests in any meaningful way. T______T
The Limitation of Extension:TL
Unfortunately, it's unidirectional. After a page is marked up for translation, the raw text, which happens to be the only editable text, needs to be at
page. The child pages,
page/$lang cannot have more sections than defined in the raw.
Basically, this means the child pages cannot have novel content. Once the "
mark up for translation" button is used, the child pages are forced to undertake the structure of the parent page. The child pages cannot even cut content. If sections are not filled in, by default, the parent page material will leak into the child page.
The issue I have is that it seems like you can't modify the section markers manually:
The software likes to generate the section markers automatically (it likes to put them at paragraphs), and it won't let me play with them. @_____@; I do think it's possible for
Translation Administrators (the privilege I don't have), to play a little with them, but the Help Page says they can't add sections either. IDK if it's possible to remove/merge sections. If you could make the entire thing one huge section, naturally that would solve problems, but I can't get that to work with my current privileges.
With these issues in mind, here's the implications:
- The structure of the child pages have to be similar to the parent pages. They can't be drastically different. The workaround for this is if we can get the <!--SECTION--> to wrap the entire raw and not every paragraph.
- Areas of the raw/parent not wrapped by <translate> will end up showing up in the child pages wherever it's corresponding location is.
- Sections not yet translated will end up displaying the raw.
- The parent (raw) cannot be incomplete material. This is because of the way the sections are generated. Basically, the it can't be used as a small piece of Japanese or Chinese that we want to verify for accuracy (TLG's 3rd suggestion). At least, it can't be used in that direction. The raw page needs to be complete in order for the child pages to work off of it.
- Translations are unidirectional. The visual editor won't let you go from Child-->Raw or Child-->Child. It only works Raw->Child.
There's only a slight bit of good news: wikicode works inside of the translate editor.
But you're forced to use that tiny visual editor. Unless you're on the parent (raw) page, you can't use the regular source editor anymore. This will become an issue if we manage to get the merged <!--SECTION--> workaround to work.
Despite this, I present my evaluation here of plausible ways it could work:
(Dummy) Proposal: Using Extension:TL for Project Pages
Not a good idea.
We can use the file naming structure, but <translate> tags on the project pages are going to be messy. Very very messy. The good news (which is also the bad news for all other situations) is that whenever someone puts in the <translate> tags,
you can't start translating things right away. They need to be approved by a Translation Administrator. So we won't be having blowing up Project Pages from people suddenly deciding to put <translate> tags around the English.
I said this was a hassle above, but it's a security step. I have the impression once the page is newly "Marked for Translation", it'll overwrite the content on the old
page/$lang page (that wasn't marked for translation yet). This is actually a valid argument why we
shouldn't use use the
page/$lang naming structure for alt language projects.
I mean, it's
certainly doable. The Translation Administrator just needs to make very big <!--SECTION--> blocks, and the alt language users will need to be okay with using the visual editor. In either case, I do think Alt. Language users get the short end of the stick if they have to do extensive non-translation formatting within the visual editor built into Extension:TL.
Proposal: Using Extension:TL for English TLC
Incomplete Japanese/Chinese cannot be the raw. We've established that. However, it can work the other way around.
For example, the raw/parent can be English.
Once they publish the raw page, and the page gets approved by a Translation Administrator, the translator can then go to the Japanese child or the Chinese child page and add the raw text they were unsure about.
The only issue is that no one would actually know to check the Japanese Page or Chinese page for the problematic text. On the english page, you'd probably need a template flag/stamp that tells people to check the Japanese/Chinese child pages for problematic sections.
From there, the TLC-er will need to read the Japanese/Chinese page, search through a sea of english for wherever that single line of Japanese text is, remember the location, and then go back to the edit raw english.
You cannot edit/translate from child page --> raw. You also cannot edit/translate from child page --> child page. Remember how the extension is unidirectional? Basically, the TLC-er will need to exit the screen and search for the location of the issue in the raw Wikitext.
Cloud's opinion: It's actually a really big hassle. We might as well just paste the section we have a TLC issue with on the Talk page... But IDK, it's possible. One of the issues in the implementation here is that the translator needs to wait for a Translation Administrator to approve the <translate> tag markup.
Proposal: Using Extension:TL for English --> Aux Projects
This works. I mean, this is what the TL:Extension was designed for.
It's designed for translation from one single raw source that is already complete.
In this case, English would be in the raw, and the aux project would be in the child page.
This is the situation where everything is nice and easy. <3 The only issue is that it only favors EN --> ALT language translators. It doesn't really favor JA --> ALT language translators at all who don't want to see the English. You can't go hybrid in this system.
Proposal: Using Extension:TL for RAW (English translation) --> English Child (edits)
KuroiHikari's suggestion. It certainly works. I have nothing to say against it. xD
My main issue is the unidirectionality of the extension. And also the security/ease of use with the Translation Administrator... and also the difficulty of implementing the extension with non-word-for-word Alt. language pages like Project Pages and Main Pages and what not.