2014 Jan- New wiki extensions

Updates, News on the Baka-Tsuki Project

Moderators: thelastguardian, Fringe Security Bureau, Senior Editors, Senior Translators, Alt. Language Translator/Editor, Executive Council, Project Translators, Project Editors

User avatar
cloudii
Project Translator
Posts: 512
Joined: Mon Mar 25, 2013 4:30 pm
Favourite Light Novel: Ahouka!
Location: awkward buttface
Contact:

Re: 2014 Jan- New wiki extensions

Post by cloudii »

To give my honest opinion, it seems like it's getting harder to find useful applications of this..... From a translator's perspective. Also (IDK if this is intentional), you need to get pages marked for translation approved(?). I tried put in the translate tags the other day but it wouldn't work unless someone which privileges comes through and approves it.

Unless (I'm going to say something crazy that's going to deserve a *whack* from Simon again, but I'll say it because I'm shameless @___@, and because I feel like it's the only thing that might make the TL extension worthwhile at all)...

Since fan translations are such a moral gray area in the first place... umm... *shamelesslycoverseyes* we could install a extension/hack that restricts access to pages. In particular, we restrict access to the root chapter page so they're viewable only to users in the translator usergroup, in which we post the full raw. Since the access is restricted, regular people can't run around and read the raw. We'd also need to have translators prove that they're on Baka-Tsuki to translate, and not shamelessly read raws. @____@

Yup. @///////@... *embarrassed* ...this is never going to happen. Because it pushes us even more into the moral grey area, and it involves using extensions to MediaWiki that actually aren't secure. XD But I said it because it's the only way I can imagine the extension ever becoming useful from a translator's perspective.

KuroiHikari's suggestion has merit, I guess. But I think at this point we're scratching for straws. XD I think this Translation Extension is only ever going to be useful for English-->Alt Language projects.
Twitter: @cloudiirain | BT Userpage | OreShura Translator | Biblia Editor (@HereticLNT) | Clockwork Editor (@HereticLNT)
User avatar
cloudii
Project Translator
Posts: 512
Joined: Mon Mar 25, 2013 4:30 pm
Favourite Light Novel: Ahouka!
Location: awkward buttface
Contact:

Re: 2014 Jan- New wiki extensions

Post by cloudii »

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:

Code: Select all

<!--T:1-->
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.
Twitter: @cloudiirain | BT Userpage | OreShura Translator | Biblia Editor (@HereticLNT) | Clockwork Editor (@HereticLNT)
User avatar
onizuka-gto
Editor-in-Chief
Posts: 4840
Joined: Wed May 10, 2006 9:02 pm
Favourite Light Novel: Suzumiya Haruhi
Mahouka koukou no Rettousei
No Game No Life
Mushoku Tensei
Mother of Learning
Location: N.E.E.T Federation
Contact:

Re: 2014 Jan- New wiki extensions

Post by onizuka-gto »

....

TL:DR

Can i have a summary? :D

Once i get my head round the concepts you are trying to explain above, i'll start to look into it deeper to understand what is the current situation with the above mention wiki-related....thing. :lol: :roll: :wink:
"Please note, we have added a consequence for failure.Any contact with the chamber floor will result in an unsatisfactory mark on your official test record, followed by death. Good luck."

@Onizukademongto
User avatar
EusthEnoptEron
Project Translator
Posts: 836
Joined: Mon Jul 13, 2009 10:39 am
Favourite Light Novel: Ahouka!
Location: Switzerland

Re: 2014 Jan- New wiki extensions

Post by EusthEnoptEron »

Thanks for the report, cloud. :D

One thing I really don't like about the translation editor is that it's bound to the parent page and its sections. It's too restrictive.
I don't know about others, but I often find myself restructuring sentences / paragraphs when translating / editing. By using the extension, you'd be forced to orientate yourself strictly by the parent page, which would mean that you could only edit paragraphs as they appear in the raw translation, and that you have to adopt the exact same structure as the English version for your translation. I don't know how well that works for international prose, since every language has its quirks and translators might like to have more freedom.
The most prominent case that I see here are dialogues; the English translation might adopt the Japanese new lines after every line of dialogue, while an alternative language translator might want to make an effort and use the "blabla," said Romeo rules of his language.

It's a fancy gadget, but I'd honestly prefer passing on the translation editor itself and just take the naming scheme and the language bar. Although a pure unified naming scheme would throw up a bunch of new problems, namely the problem of ugly, uncustomizable page names for all derivatives.
cloud wrote: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. @_____@;
Manual wrote:When editing the page, the markers should be left alone and their position in relation to the unit they belong to should not be changed. When moving a unit, move the unit marker, too. When deleting a unit, delete the marker too. When adding new paragraphs, new markers will be added by the software. Do not try to do this manually, it may confuse the software.
-> I think there's no way around using the paragraphs defined by the extension.
User avatar
cloudii
Project Translator
Posts: 512
Joined: Mon Mar 25, 2013 4:30 pm
Favourite Light Novel: Ahouka!
Location: awkward buttface
Contact:

Re: 2014 Jan- New wiki extensions

Post by cloudii »

EusthEnoptEron wrote: -> I think there's no way around using the paragraphs defined by the extension.
This was what I was reading: Changing the Source Text

To summarize, it looks like you can:
manual wrote: Deleting text. You can delete whole units. If you do so, also remove the unit marker.

Splitting units. You can split existing units by adding an empty line in the middle of a unit, or by placing translate tags so that they split the unit. You can either keep the unit marker with the first unit or remove it altogether. In the first case, translators see the old text when updating the old translation. If you removed the unit marker, both units will behave as if no translation ever existed, after the page is re-marked for translation.

Merging units. If you merge units, you have to remove at least all but one unit marker. (<--This is what interests cloud, but it's awfully vague.)

Moving units. You can move units around without invalidating translations: just move the unit marker together with the rest of the unit.
You just can't:
manual wrote:General principles:
  • Avoid changes
  • Make the changes as isolated as possible
  • Do not add translation unit markers yourself
Sounds contradictory, but if I'm reading it correctly, you just can't add sections manually. It looks like the manual says it's okay to delete/rearrange/move sections manually (but proceed at your own risk).

But then again, I can't even test this because we don't have Translation Administrator privileges. XD
Twitter: @cloudiirain | BT Userpage | OreShura Translator | Biblia Editor (@HereticLNT) | Clockwork Editor (@HereticLNT)
User avatar
EusthEnoptEron
Project Translator
Posts: 836
Joined: Mon Jul 13, 2009 10:39 am
Favourite Light Novel: Ahouka!
Location: Switzerland

Re: 2014 Jan- New wiki extensions

Post by EusthEnoptEron »

Ah, I see. I interpreted the "merging" part as merging two paragraphs together, which would naturally result in deleting one of the markers.
Anyway, you nailed it:
But then again, I can't even test this because we don't have Translation Administrator privileges. XD
User avatar
cloudii
Project Translator
Posts: 512
Joined: Mon Mar 25, 2013 4:30 pm
Favourite Light Novel: Ahouka!
Location: awkward buttface
Contact:

Re: 2014 Jan- New wiki extensions

Post by cloudii »

Worst-case scenario (and I really mean worse case), we could have a paragraph-free raw, and add the paragraphs in the child pages (En/Fr/etc), and display only the "page/en" to readers.

You can go from one section (one paragraph) in the raw to one section (yet many paragraphs) in the child.

I'm curious whether the software considers the double line break or single line break as a "paragraph". But, I suppose we'll find out if anyone ever get Translator Administrator privileges (it's currently restricted to sysops!).
Twitter: @cloudiirain | BT Userpage | OreShura Translator | Biblia Editor (@HereticLNT) | Clockwork Editor (@HereticLNT)
User avatar
Simon
Editor-in-Chief
Posts: 508
Joined: Wed Dec 28, 2011 9:06 am
Favourite Light Novel:
Location: !=

Re: 2014 Jan- New wiki extensions

Post by Simon »

EusthEnoptEron wrote:Ah, I see. I interpreted the "merging" part as merging two paragraphs together, which would naturally result in deleting one of the markers.
Anyway, you nailed it:
But then again, I can't even test this because we don't have Translation Administrator privileges. XD
As the ones here are technologically adept, there is a link in the second group from the end in special pages. Then you setup a local wikimedia installation with the plugins that you need and do the rervese of what you did in special pages.

Wither way. I'm not a TL nor am I an editor, so I'll stay out this one.

@TLG
Check your mail. If you ever read these boards.
ePUB Generator <<Productive>> : BTE-GEN | Yay, I'm free. Let's see how long it takes for this place to go down.
Ansem2
Reader
Posts: 8
Joined: Sun Feb 16, 2014 7:03 am
Favourite Light Novel:

Re: 2014 Jan- New wiki extensions

Post by Ansem2 »

i'm only a user, not a translator, but:
Collection (ie. build PDF support)
One of the oldest requested features is back. As some of you might remember, BT at one point had to disable Collection due to performance issues with site crawlers. After some testing, the extension is deemed suitable for production usage. Note that it might freeze with large pages. The issue is fixable, but it's lower on my priority list right now.
Another interesting feature from this extension is the ability to construct a virtual book made up of wiki pages. I will leave how to use this to you guys.
https://www.mediawiki.org/wiki/Extension:Collection
Why PDF and not epub? T_T for all the ebook reader users the epub format it's really a lot better than pdf!
User avatar
yoyoyo5678
Project Editor
Posts: 193
Joined: Sat Aug 03, 2013 1:24 pm
Favourite Light Novel:

Re: 2014 Jan- New wiki extensions

Post by yoyoyo5678 »

Ansem2 wrote:i'm only a user, not a translator, but:
Collection (ie. build PDF support)
One of the oldest requested features is back. As some of you might remember, BT at one point had to disable Collection due to performance issues with site crawlers. After some testing, the extension is deemed suitable for production usage. Note that it might freeze with large pages. The issue is fixable, but it's lower on my priority list right now.
Another interesting feature from this extension is the ability to construct a virtual book made up of wiki pages. I will leave how to use this to you guys.
https://www.mediawiki.org/wiki/Extension:Collection
Why PDF and not epub? T_T for all the ebook reader users the epub format it's really a lot better than pdf!
PDF was chosen because - everyone can use it and epub can't be in use by everyone.
Link to my user on B-T
Post Reply

Return to “News”