PHP - Interested in making Translating more efficient

[Jazz]

Code Select Expand


    <?PHP
     if(!isset($knowledge_in_php) {
         echo "This isn't for you!";
     }else{
       
If this all makes sense - then you are in the right place. I know this isn't quite as related to programming for gaming however, I'm an enthusiast for web coding and design, and for this community - not that this is a hiring advert but I'm gauging if there is anyone here that is passionate with MYSQL/SQL and/or PHP that would be interested in working on a project related to assisting game translators work efficiently with some online tools.

Code Select Expand


    <?PHP
       } // end else
     ?>
       

[FAST6191]

We had a quick discussion on node.js the other month in case you missed it
http://www.romhacking.net/forum/index.php/topic,15480.0.html

Still I have also seen people use a bit of ruby and go in for some of the adobe/flash type languages though those are not strict web dev affairs so I can see some potential.

I have used a few websites for translation projects though most php seems to be for save modification, cheat making (cases where you have several hundred options for a potential cheat).

I will say though XLIFF (the main contender for an open source format for CAT tools) is not bad, certainly no worse than half the nonsense that grew out of the VBscript era. Equally wikis are nice and many CMS tools (also good things in hacking projects) even have one built in (one of my favourites in fossil especially and then we have git which does pretty well here as well).

Short version- you are probably facing something of an uphill battle to convince many people around here that web hosted tools are a truly good idea.

[Jazz]

I was thinking more along the lines of using PHP as this is the language I am most common with and would be great to work with someone else to half my work load.

Tools I had in mind were

• Japanese script submission for people to comment, translate and add within that page of the text
• Quick tablefile makers
• Algorithm testers
• Quick Japanese word references (game related, slang, urban etc) and general conversation related.
• Really anything that could be web based that currently only C/C++ programs are built for.

All in the one website, which could be sub-hosted or included into RHDN if the staff approved.

This will help people who use multiple platforms and not just their own PC to do this type of work. Also hopefully save having to download, install every time you get a new device you could simply login or vist the site with all the tools running live.

[Rhys]

No love for Python?

[Jazz]

No love for Python?

I'm just really unfamiliar with Python

[Zoinkity]

This isn't a bad idea.  I've seen similiar things at drama subtitling sites.  Granted that's a little different, but the way they have it set up is like so:

All text entries are in their own seperate windows.  These windows are split in four parts: one for original content, one for rough translation, then a final translation, with the fourth window reserved for notes and discussion.  Yes, that amounts to a lot of windows to handle all the text (a typical 1hr drama winds up in the thousands), but each snippet is very small.
Basically, you submit all translations like you would a wiki, except the display is more like the way history pages work.
When a translation is as good as it gets, that window gets locked, which incidentally limits the available text to just the final.

Obviously the moderator (usually the main editor) handles registering translators (or banning them), accepting changes, and locking good text.
Generally there's a page for reserved words and accepted name translations.

Anyway, it does work in other applications.  Of course, scripts are only half the battle with ROM hacking, but that is half the battle.

[Pennywise]

I don't want to diss your idea, but I think using something like Google Docs is probably the best option. It has pretty much everything you need for managing a translation and whatever misc thing it lacks can be found elsewhere.

[Jazz]

It's the same reason you have a website when RHDN is a perfect hub for your news and patches. Convenience and a sense of ownership.

Google docs is handy for a portion of what I am thinking.

[JurasskPark]

http://jurasskpark.magicteam.net/tmp/images/php~1.jpg
http://jurasskpark.magicteam.net/tmp/images/php~2.jpg
0.1 beta version
P.S. PHP 

[Jazz]

Now that's what I'm talking about except the russian characters confuse me lol.

[Dark Phoenix]

Some quick advice from another experienced PHP programmer: if you want to do non-Latin languages in PHP, be very careful about encoding.  I had to do a site that simply showed two different languages (English and French), and it would have been a disaster if not for the fact I was somewhat aware of the problems that can crop up due to encoding.  For tools that actually process non-Latin characters, I'm betting the hurdles are even larger.

[Bisqwit]

My tool-set for Simon's Quest translation is written in PHP.

You can find my linker for instance here: http://bisqwit.iki.fi/src/romlinker_php.zip
It includes a PHP class that accepts binary "blobs" that may declare labels and may include pointers to other labels, and a method for declaring constraints for the linkage of each blob (which page they must put in, or which fixed address they are placed in), and a method for automatically deciding the locations for those blobs based on a listing of free space locations in the ROM.

Just sharing it here for the benefit for other ROM hackers who might use PHP for their tools.

It is basically the lite version of the O65 linker that I used in Chronotools. It only supports 16-bit pointers; no fixups, no offseted relocations, no low-byte or high-byte or page-byte references.

(This message is not about volunteering for your project, sorry.)

[Neil]

Suddenly your extremely long page showing translation differences seems more human. I imagine you just dumped most of that out of a database from existing code.

[Bisqwit]

Suddenly your extremely long page showing translation differences seems more human. I imagine you just dumped most of that out of a database from existing code.

Why do manually what you can automate?