Announcement

Collapse

Please use the Hentai ID thread for all hentai ID requests. Click me for link!

The Identification Thread is Here:

http://www.hongfire.com/forum/showthread.php/447081
See more
See less

Translation Aggregator

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Translation Aggregator

    I'm no longer working on Translation Aggregator, but Setx has released an updated version, here. The files attached directly to this post are now outdated

    Translation Aggregator basically works like ATLAS, with support for using a number of website translators and ATLAS simultaneously. It was designed to replace ATLAS's interface as well as add support for getting translations from a few additional sources. Currently, it has support for getting translations from Atlas V13 or V14 (Don't need to have Atlas running), Google, Honyaku, Babel Fish, FreeTranslations.com, Excite, OCN, a word-by-word breakdown from WWWJDIC, MeCab, which converts Kanji to Katakana, and its own built-in Japanese parser (JParser). I picked websites based primarily on what I use and how easy it was to figure out their translation request format. I'm open to adding more, but some of the other sites (Like Word Lingo) seem to go to some effort to make this difficult.

    JParser requires edict2 (Or edict) in the dictionaries directory, and supports multiple dictionaries in there at once. It does not support jmdict. You can also stick enamdict in the directory and it'll detect some names as well, though the name list will be heavily filtered to avoid swamping out other hits. If you have MeCab installed, JParser can use it to significantly improve its results. TA can also look up definitions for MeCab output as well, if a dictionary is installed. In general, MeCab makes fewer mistakes, but JParser handles compound words better, and groups verb conjugations with the verb rather than treating them as separate words.

    TA also includes the ability to launch Japanese apps with Japanese locale settings, automatically inject AGTH into them, and inject its own dll into Japanese apps. Its dll can also translate their menus and dialogs using the ATLAS module (Requires you have ATLAS installed, of course). Versions 0.4.0 and later also include a text hooking engine modeled after AGTH. The menu translation option attempts to translate Windows-managed in-game menus, and is AGTH compatible. The AGTH exe and dlls must be in the Translation Aggregator directory for it to be able to inject AGTH into a process. AGTH is included with the most recent versions of TA.

    The interface is pretty simple, much like ATLAS: Just paste text into the upper left window, and either press the double arrow button to run it through all translators, or press the arrow buttons for individual translation apps. Each algorithm is only run once at a time, so if a window is busy when you tell it to translate something, it'll queue it up if it's a remote request, or stop and rerun it for local algorithms. If you have clipboard monitoring enabled (The untranslated text clipboard button disables it altogether), it'll run any clipboard text with Japanese characters copied from any other app through all translators with clipboard monitoring enabled. I won't automatically submit text with over 500 characters to any of the translation websites, so you can skip forward in agth without flooding servers, in theory. I still don't recommend automatic clipboard translation for the website translators, however.

    To assign a hotkey to the current window layout, press shift-alt-#. Press alt-# to restore the layout. Bound hotkeys will automatically include the current transparency, window frame, and toobar states. If you don't want a bound hotkey to affect one or more of those states, then you can remove the first 1 to 3 entries in the associated line in the ini file. Only modify the ini yourself when the program isn't running. All other values in those lines are mandatory.

    Pre-translation substitutions modify input text before it's sent to any translator. Currently applies to websites, ATLAS, Mecab, and JParser. There's a list of universal replacements ("*") and replacements for every launch profile you've created. I pick which set(s) of substitutions to use based on currently running apps. Note that you do not need to be running AGTH or even have launched a game through TA's launch interface for the game to be detected, but you do need to create a launch profile. May allow you to just drag and drop exes onto the dialog in the future.

    MeCab is a free program that separates words and gives their pronunciation and part of speech. I use it to get the information needed to parse words and display furigana. If you have MeCab installed but I report I'm having trouble initializing it, you can try copying libmecab.dll to the same directory as this program. Do not install MeCab using a UTF16 dictionary, as I have no idea how to talk to it (UTF16 strings don't seem to work). Instead, configure MeCab to use UTF8, Shift-JIS, or EUC-JP. If you have both MeCab and edict/edict2 installed, you can view a word's translation in MeCab by hovering the mouse over it. Also, JParser can use MeCab to help in parsing sentences.

    JParser tends to be a better choice for those who know almost no Japanese - it tells you how verbs are conjugated, handles some expressions, etc. MeCab may well be the better choice for those who know some Japanese, however.

    Source, attached below, is available under the GPL v2.

    Thanks to (In alphabetical order, sorry if I'm leaving anyone out):
    Hongfire Members:
    Freaka for his innumerable feature suggestions and reported issues over the course of development.
    Setsumi for TA Helper and for all his suggested improvements and reported issues, particularly with JParser.
    Setx for AGTH.
    Stomp for fixing the open file dialog not working properly on some systems and adding the tooltip font dialog, and fixing a bug that required admin privileges when certain other software was installed.
    Might sound like minor contributions, but feedback really drives the development of TA.

    Non-members:
    KingMike of KingMike's Translations, who is apparently the creator of the EUC-JP table I used to generate my own conversion table.
    Nasser R. Rowhani for his function hooking code.
    Z0mbie for writing the opcode length detector/disassembler I use for hooking. Apparently was intended for virus-related use, but works fine for other things, too.
    And the creators and maintainers of edict, MeCab, and zlib.

    You might also be interested in:
    *Setsumi's TA Helper and AGTHGrab.
    *errotzol's replacements script.
    *Devocalypse's devOSD.
    *kaosu's ITH (Like AGTH. No direct TA support, due to lack of a command line interface, but definitely worth checking out).

    MeCab
    edict2

    Changelog:
    0.4.9
    * Fixed MeCab/JParser getting stuck when starting a new translation before the last is fixed.
    * Fixed interface lockup while mousing over an item in MeCab while JParser is running.
    * Menu translation will now translate column headings in ListViews (Needed this for the AA launcher)
    * Fixed ATLAS config crash.
    * Global hotkey support. Toggle under "File" menu (Tools is kinda big already). Currently only really supports history navigation. May add more later.

    0.4.8
    * Added history. Logs both original text and translations (For online translators). It logs up to 20 MB of original text, and whatever translations are associated with it. Currently only way to force a retranslation is to toggle one of several options (Autoreplace half-width characters, src/dest language, modify substitutions).
    * Fixed deadlock bug on MaCab mouse over while JParser is running.
    * Fix corrupting built-in text hooker settings when launch failed. Suspect no one uses this, anyways.
    * Drag/dropping an exe onto TA to open up the injection dialog now actives TA.

    0.4.7
    * JParser and MeCab each use their own thread (Mostly).
    * Changed conjugation table format to JSON - plan to do this to a lot of other files (Being careful not to mess up game settings or substitution tables). Currently have way too much file loading code.

    0.4.6
    * Fix WWWJDIC
    * Fix closing injection dialog
    * Updating process list 10+x faster
    * Process list autoupdates
    * Fixed bug that would result in injecting into wrong process when one program is running multiple times.
    * Updated included AGTH version

    0.4.5
    * Added bing support.
    * Updated Honyaku code (They didn't try and block TA, they just modified their HTML)
    * Fixed AGTH command line code.
    * Replaced "/GL" with "/SM" compile option, resulting in faster builds when one has a lot of cores.

    0.4.4
    * Regular expressions are now compiled
    * Injection validation when using addresses relative to dlls (Or function addresses in dlls) should be fixed.
    * Added option to create shortcuts. They'll launch TA (If it's not running) and try to launch the game using the current injection settings (Injection settings that you'd get at the launch screen - the current settings are not saved - it always uses the most recently used ones).
    * Appropriated some of Setsumi's code to make tooltips larger.

    0.4.3
    * Multiple subcontexts now supported. Separate them with semi-colons. AGTH code converter will add two subcontexts, when appropriate.
    * Using aliases for hooks added. Prefix a hook with "[Alias Text]" and that's what will be displayed on the context manager screen as the hook's name. Makes it easier to see context strings.
    * Locale selection added to injection dialog.
    * "Hook delay" added to injection dialog. Actually doesn't delay hooking, delays how long before hooks that use filtering based on calling function's dll are enabled. Generally only the default hooks do this. Increasing this delay may circumvent issues with games that crash when launched with AGTH, but work fine when injected after launching.
    * Added "!" and "~" operators.

    * Stomp's admin privilege fix when using some 3rd party software added.
    * Excite fixed
    * Fixed sanity testing for injection addresses, so when specify a dll or exe name in a text hook, shouldn't erroneously think it's an error when the module isn't loaded in the current address space.
    * Fixed some JParser dicrionary common word parsing, when using versions of edict with entL entries. Also changed treatment of Kanji entries when only their corresponding Hiragana are marked as common.
    * Fixed substitution matching Hiragana with Katakana and vice versa.
    * Fixed a clipboard-related crash bug.
    * Fixed hooks causing crashes when relocating call/jumps (Hopefully...)
    * Fixed AGTH repeat filter length placement (oops).

    0.4.2b
    * Fixed substitution loading/deleting.
    * Fixed << and >>.

    0.4.2
    * AGTH code conversion tool.
    * Injection code checker added.
    * New child process injection handler (Really nifty injection code for that...). Should be a little more robust than before.
    * Option not to inject into child processes added.
    * Auto copy to clipboard added.
    * Both extension filters fixed.
    * Both eternal repeat filters fixed/upgraded.
    * Phrase repeat filter fixed/upgraded.
    * OpenMP/MSVC 2008 SP1 runtime requirement removed
    * char/charBE fixed
    * GetGlyphOutline fixed
    * Copy to clipboard crash when auto translate disabled fixed.
    * Slightly improved dll injection error handling.

    0.4.1
    * More context/filter options.
    * Repeated phrase filter now handles cases where phrase is being extended by a couple characters each time (xxyxyz, etc). Extension filters no longer really needed, unless the repeat starts out too short.
    * Option to handle eternally looping text.
    * Option to ignore text without any Japanese characters.
    * Text which substitution rules reduce to nothing no longer overwrites translated text.
    * Log length limit added.
    * Options to manage default internal text hooks added.
    * Clipboard treated as a context. Its default settings should mirror the old handling.

    0.4.0
    * Added it's own text hooking engine. Probably still buggy.
    * Fixed excessive redrawing when a hidden furigana window had clipboard translation enabled.
    * Works with new, even more poorly formatted edict files.
    * Handles EUC_JP characters that Windows does not (Doesn't use them properly with WWWJDIC at the moment, however). Only really fixes loading edict files with those characters.
    * Fixed right clicking when full screen.
    * Fixed not checking auto Hiragana mode.
    * Less picky when reading MeCab output.
    Attached Files
    Last edited by ScumSuckingPig; 07-11-2015, 11:20 AM. Reason: Change download link, re-upload attachments upon request from Setx

  • Stomp: None of that looks to be relevant, unfortunately, though it sounds like the same issue.

    errzotl80: Not sure what the "#1" does (Doesn't seem to be documented...) but for everything else, it would be something like:

    wchar:[_EAX + 20]:[_EAX]@<address>, whatever address is.

    As I have no idea how kikiri detection works, and don't feel like reverse engineering it from AGTH's binary, and have never found a kikiri game that I cared for, it's unlikely that I'll add built in kikiri support myself. I suspect most kikiri games will work with the default hooks as well, though may have to disable the default filters by calling function in the injection launch screen.

    Also note that specifying user hooks has yet to be tested at all, so may well just not work yet.

    Edit: Should add that I recommend against using aggressive extension filtering unless you need it. Think there are a couple cases where it ends up being over aggressive, though I could be wrong.
    Last edited by ScumSuckingPig; 05-13-2010, 05:49 AM.

    Comment


    • I had Visual C++ 2008 Express installed. I need for my application. I commented out this line (line 1450)
      Code:
      CoInitializeEx(0, COINIT_MULTITHREADED);
      in "Translation Aggregator.cpp" and recompiled TA. Now I see drives in "My Computer".
      AGTH wiki

      Comment


      • Erm...Completely forgot about that line, was getting it confused with initializing common controls (Which I most definitely don't pass the argument "COINIT_MULTITHREADED" to). Regardless, still has to be called or the rich edit controls can misbehave very badly. Try using:

        Code:
        CoInitializeEx(0, COINIT_APARTMENTTHREADED);
        I do modify the contents of the rich edits from multiple threads, but as they all run in the same thread, shouldn't be an issue....

        Comment


        • I changed it like you said and I see the drives in "My Computer".
          AGTH wiki

          Comment


          • Looks to be working with the rich edit control too (Currently only used by WWWJDIC for the color - mecab used it before I added furigana support as well). Anyways, I'll modify the source and the next release will have the fix. Thanks for looking into it. Never woulda gotten around to it myself.

            Comment


            • Originally posted by ScumSuckingPig View Post
              errzotl80: Not sure what the "#1" does (Doesn't seem to be documented...) but for everything else, it would be something like:
              # = "number of stack frames to backtrace from the given addr". Basically if you know that a certain engine doesn't output all text to textout due to some caching mechanism, but always passes the fulltext as parameter earlier relative to that textout you can use it without having to use a debugger for each game. I believe it works in a way of putting some sort of breakpoint at the given addr, then the first time it is passed the real breakpoint is calculated from stack frame and used from there on.

              It isn't supported anymore by the most recent version of agth (2008.11.20), though it was supported nearly until the last (2008.10.17 http://agthook.googlepages.com/agth_prev.rar). It can be very useful to create generic codes for engines, although that kirikiri code might not work anymore due to engine changes in the meantime.

              Comment


              • Ohh...Can backtrace by hand with my scheme...but it's a bit of a pain... Might add a macro for it, though then I'd have to work out the pointer arithmetic.

                Edit: Though come to think of it, if you can backtrace to an earlier stack...Why not just put the hook there as well? Suppose could get the string and context from different frames...
                Last edited by ScumSuckingPig; 05-13-2010, 12:43 PM.

                Comment


                • Probably releasing this prematurely, but here's a version with (some) hook codes actually working. I hadn't realized that AGTH's raw addresses were raw addresses, rather than offsets relative to the exe's base address, and my handling of charbe/char were reversed, if I want to stick with AGTH's definitions (Were also a couple related bugs in char handling). There are still undoubtedly bugs, but thought I'd give people something to play with (And hopefully find bugs with, saving me the effort of searching for tons of games with AGTH codes).

                  Still need to test a lot more games, but at least it works in some cases. Also, I added support for binary operators to my evaluator (^, &, |). Priority same as multiplication, due to laziness.
                  Last edited by ScumSuckingPig; 05-13-2010, 09:37 PM.

                  Comment


                  • Originally posted by ScumSuckingPig View Post
                    Edit: Though come to think of it, if you can backtrace to an earlier stack...Why not just put the hook there as well? Suppose could get the string and context from different frames...
                    The idea is to get the addr just from looking at the hooks it gets automatically (e.g. textouta:454343) and being able to say, take that 454343 and go back 2 frames and place the hook there, because that always works with that engine. That enables users without ollydbg to make some hooks, for anybody who can use olly those are easy hooks todo ofc.

                    I'm not sure I like having _ much. I mean you got rid of ABCWU etc. because they were to cryptic, doesn't _ do that again. When the /H-code has a positive number you'd use ESP+something, as positive numbers refer to the stack, negative to EAX, EDX etc. /HA-4 <= EAX /HA4 <= ESP+4 with the only exception being /HA-14 as -14 = ESP

                    And regarding referencing:
                    /HS-4 means EAX has an address which points to the start of a sjis string.
                    /HA-4 means EAX has a sjis char as value.
                    /HA-4*0 means EAX has an addr which points to a sjis char.

                    So if there would be a 0-terminated string which only consists of a single char /HA-4*0 and /HS-4 would read the same. If there would be multiple chars as value on EAX it's not possible to read all with agth (I don't think I ever encountered that problem in practice though).

                    /HS-4*0 means EAX has an addr which points to another addr which points to start of the string.
                    /HA-4*7 means EAX has an addr, add 7 to that addr and it points to the char to read

                    Comment


                    • _x is unnecessary...Can just [ESP+x] instead. That seems to be what /HAx means, so it's just a simple macro.

                      Let's see then, so

                      <Not completely correct list removed, see 2 posts down>

                      Think that's a complete list,

                      So, say, "4" means something completely different in the first and second position, but -4 means the same. That's what I find so odd about the format. char/char* makes no difference in the conversion.

                      Underscores are mostly for people who don't know ESP from EBP from EAX. AGTH docs can be used to look up the register mappings, but they say nothing about ESP. Note that my versions of /H*-4 and /H*4 look a little more similar with underscores than they do without them, since the 4 includes an implicit memory dereference, which the -4 does not. Whether that's sufficient reason to warrant a macro or not, I'm not sure.

                      You could argue that I should do the same (That is, map 4 to [ESP+4]), but the cool thing about my method is I use identical code to parse all fields...so if you want to use Japanese as the language, 932 means 932, rather than [ESP+932]. Same is true of length and subcontext (Useful for a "0" subcontext, when you don't want one instead of using another value to indicate that). Also, [4+EAX] and [EAX+4] should map to the same thing, of course. Constant length is probably rarely necessary, anyways, but you never know.
                      Last edited by ScumSuckingPig; 05-13-2010, 10:15 PM.

                      Comment


                      • Sorry, that's a misunderstanding:

                        /HA8*-4 = char:[[ESP+8]+EAX] = char:[_8+EAX]
                        -4 is not EAX in that case, * denotes a pointer and the number behind that is addition/substraction from the addr. It would be only EAX again for subcontext if it would be after : e.g. /HA8*-4:-4 then the second -4 would be EAX. In your examples it seems to me you sometimes ignored the switch from /HS to /HA and used the same code?

                        Comment


                        • So this:

                          /HS-4 = char*:EAX
                          /HA-4 = char:EAX
                          /HA-4*0 = char:[EAX]

                          /HS-4*0 = char*:[EAX]
                          /HA-4*7 = char:[EAX+7]

                          /HS8 = char*:[ESP+8] = char*:_8
                          /HS8*7 = char*:[[ESP+8]+7] = char*:[_8+7]
                          /HA8 = char:[ESP+8]
                          /HS8*7 = char*:[[ESP+8]+7]

                          /HA8*-4 = char:[[ESP+8]-4] = char:[_8-4]
                          /HS8*-4 = char*:[[ESP+8]-4]
                          /HA-4*-8 = char:[EAX-8]
                          /HS-4*-8 = char*:[EAX-8]

                          More accurately, I overlooked the switch from HA to HS (In other words, wasn't deliberate). Anyways, it seems to make no difference, in terms of the memory address specified. Once the address/value is resolved, I do the same thing as AGTH (Or should be doing, modulo bugs), and we both use a consistent function, regardless of whether it's a pointer or not.
                          Last edited by ScumSuckingPig; 05-13-2010, 07:58 PM.

                          Comment


                          • Yeah, that's looking good.

                            AGTH crashes if the pointer is invalid, does the same happen to TA?

                            One additional feature could be (dunno if that might require big changes) to specify whether the hook should executed before or after the hooked commands. AGTH parses first the hooking and then the commands that were hooked away. This can be an issue regarding the asm space, say you want to put your hook after that command was executed, but there aren't 5 bytes left before a conditional jmp comes.

                            Actually, this might be less of an issue due to you allowing to make calculations. Say if I need a pointer EAX+EDX then with AGTH I need to hook after that happens in the asm code, but I guess it's easier to do with TA.

                            Comment


                            • I currently crash on bad hook address pointers, and on bad char*/wchar* pointers, but the pointers within my expression are checked, so char:[EAX] doesn't crash if [EAX] can't be read, but char*:EAX will crash. char*:[EAX] would also currently crash in that case, I believe, since I don't check the return error state.

                              Not sure if it's worth checking all pointers are not, though it's easy enough to do so. I could pass a message about the error along, but then if you have a game spamming text, you get spammed error messages.

                              Edit:: On second thought, may not crash on bad address pointers. If I can't get write access to the position, I don't do anything. If writing to a random chunk of allocated memory, I will probably crash.


                              Hmm...Hadn't thought about the before or after thing. Not sure about AGTH, but my hooker should be able to relocate relative jumps/calls. It can't handle cases where there's a jump or call to the middle of the hooked address plus 5 bytes (err...jump/call to the next 4 byte positions. Works fine on the first and 5th byte, of course). When moving code, it looks for jump/calls to relative addresses (8-, 16-, and 32-bit) and changes them all to the 32-bit versions and updates the relative address if need be. I also push the flags register and such. Should even work for jecxz and friends, which don't even have a real 32-bit jump form. A lot of this jump updating code is untested, but it's there, so just a matter of fixing any bugs.

                              If space to insert the hook turns out to be a problem, I may add the option, though then none of the relocated functions could be jumps (Well...they could be, but probably not a good idea), so it'd be a bit more restrictive in terms of what could be done that way.
                              Last edited by ScumSuckingPig; 05-13-2010, 08:36 PM.

                              Comment


                              • I'm not even sure what the exact case where, I just recall that I sometimes had the situation were usually the function would have (get passed?) a pointer parameter to the text in say EDX, but sometimes that would be empty (0x00) or some number. Best would be to silently ignore all errors, but as it worked without checking until now shouldn't be much of a priority either.

                                I'm pretty certain agth simply does not place hooks when it decides that not enough space is there and jumps are like hard walls which aren't replaced. I believe it's not aware of jumps into the hooked code and bad things happen if that is tried.

                                Sounds like your code is pretty powerful already, I really need to get some time to make some extended testings.

                                Comment

                                Working...
                                X