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

  • Originally posted by ScumSuckingPig View Post
    I'm leaning towards making everything a regexp.
    I think, this will be very bad for plain substitutions. Breaks ordering by length and using the longest that starts at the earliest position; unintuitive behavior for average users; reduced speed; no visual sorting.

    Originally posted by ScumSuckingPig View Post
    Only other options I see are:
    ...
    2) A per-string setting.
    Problem with 2 is that it wouldn't be visible when looking at a string list.
    Why not add extra column with markers?

    I think, for regexps custom order is important because they can depend on each other. Also ability to quickly enable/disable some for debug reasons is not bad.
    読んでみた。 読んでみようとした。 読めたらいいな、と思った。

    Comment


    • Originally posted by ScumSuckingPig View Post
      Currently, for simplicity, I'm leaning towards making everything a regexp. There are a couple potential issues with that: Unintuitive behavior for average users, and possibly reduced speed, if there are a lot of strings. I'm more concerned about the former than the latter. Only other options I see are:

      1) A prefix for regexps (Or non-regexps)
      2) A per-string setting.
      Everything regexp by default is bad for the reasons you already mentioned, most importantly that nobody would understand why suddenly ({/ etc behave in completely unexpected ways. I'd also agree with Setsumi to add something like a 'Regexp' checkbox to every string and show that as an extra column in the overview.

      Comment


      • I have also added support for substitutions to my app. It only supports regular expressions and they are applied one after another in the same order in that they appear in the UI. It was easy to implement it this way. The UI explicitly says that the input is a regular expression and there's a link to a reference for regular expressions, so that there should be no surprises.

        If many users start having problems with regular expression then a dialog could be added, that escapes all special characters in string and turns it into a regular expression. Like the dialog that converts from AGTH syntax to TA syntax.
        AGTH wiki

        Comment


        • Originally posted by Setsumi View Post
          fhc
          Apparently a bug.
          As a quick fix, put that name again (or translated equivalent) after Ctrl-Tab.

          Thank you very much, Setsumi, this works nicely !
          ...

          Comment


          • Originally posted by ScumSuckingPig View Post
            New settings shouldn't have anything to do with either of those issues (Neither of which I can duplicate, though I don't have that game).

            Which version of the game are you playing? The doki-doki one (/HSC@4044F0) or the original one (/HS-4@4044D0)?
            I'm playing the Original one(/HS-4@4044D0).

            to the agth "issue" i can say now, that there is no text missing in TA(original text), but in jparser and MeCab (and i guess the machinetranslators as well).

            comparison off 0.4.2 and 0.4.3:

            TA0.4.2
            TA0.4.3

            is that something you've wanted? i like 0.4.2 alot better, since there are no sentence signs missing (and that poor "he" too).the Google and systran (the free translation window) translations also make more sense with them.

            if thats wanted: why?

            edit: the window names are mostly wrong by the way... MeCab=jparser, WWWJDIC=MeCab, free translation=Systran, Honyaku=OCN.
            Last edited by tamers182; 08-18-2010, 05:51 AM.

            Comment


            • Originally posted by Setsumi View Post
              I think, this will be very bad for plain substitutions. Breaks ordering by length and using the longest that starts at the earliest position; unintuitive behavior for average users; reduced speed; no visual sorting.
              The problem with that is using one sort order for regexps, which the user has control over, and another for strings, which are handled by first occurrence, is completely unintuitive. PCRE has no ability to check only for regexps starting at position n (You can give it a start and an end, but with * and the like, end has to be the end of the entire string - resulting in a lot of redundant searching, since changes at the start of the string can affect the string further back). Also, PCRE uses UTF-8, and Windows and I use UTF16, so mixing the two replacement functions results in extremely slow behavior. Problem with me using UTF8 is it changes how case sensitivity works, as Windows has no UTF8 case-insensitive string comparison, and if I implement my own, matching behavior would change, regardless.

              Could evem make an "Add as text" button, which automatically escapes the text.


              tamers182: Curious... Probably something going on with my substitution code, which I don't think I touched in either 0.4.3a or b.
              Last edited by ScumSuckingPig; 08-18-2010, 05:58 AM.

              Comment


              • ScumSuckingPig
                I tried to comprehend your explanation, but looks like failed, so I apologize if my personal thoughts below sounds stupid.
                Substitutions as of now is amazing. You just throw in bunch of random strings and program sorts them, and intelligently applies them in specific order, position, etc. All super cool features.
                Regexes on the over hand, don't need any of these features. They more like script when user writes line after line of codes to achieve some result. I don't understand how "starting at position n" stuff have any relation to this, because user can control position by regexp itself if need arises, or else if will affect all text by default and this is desirable behavior, unlike plain substitutions, because regexps usually acts as filters - filtering the same text one after another. And all positioning/searching stuff is managed internally by the library.
                So, as this two concepts are different (and contradicting), I feel that lumping them together is not very good and sacrificing Substitutions features in the process is a waste.
                PCRE's UTF-8 only condition looks pretty horrible to me. Have you considered Boost Library? It can work with normal wide strings and famous too, i think.
                "...one of the most highly regarded and expertly designed C++ library projects in the world."

                I use it by coincidence (was conveniently bundled with C++Builder).
                読んでみた。 読んでみようとした。 読めたらいいな、と思った。

                Comment


                • Setsumi: using completely different search algorithms for RegExps (Match order determined by the user) and strings (Match the first, longest hit) doesn't appeal to me...It would mean I'd have to have different interfaces for adding regexps and strings (Order matters in one, not the other), which would mean a lot more code to deal with them, more bugs to fix, etc. Then there's the question of whether do regexps or strings first...and if I let the user set that on a per-regexp basis, that's even more complexity...

                  Using the string order for RegExps doesn't work, for reasons already mentioned. This leaves using the RegExp order for strings. Don't see any other option, without significantly increasing the complexity of my substitution code.

                  Edit: Oh, and I took a look at boost, and it's just too large for my tastes. I'm thinking I'll include a stripped-down and somewhat hacked up version of PCRE with TA, and with Boost, that doesn't really seem to work...
                  Last edited by ScumSuckingPig; 08-18-2010, 06:54 PM.

                  Comment


                  • *Sigh*...I'm thinking about going the even more complicated route...Adding dictionaries. Each dictionary has only either strings or regexps. Dictionaries are added to profiles (And each profile, by default, has it's own two dictionaries, one of each type). Each dictionary resides in its own file. Dictionaries can be ordered within a profile, and entries within a regexp dictionary can be ordered, too. For a run of string dictionaries (Allowing regexp dictionaries with 0 entries in between), substitution order uses the current algorithm - for the earliest start position, find the longest match. Then jump to the end of the replacement, and carry on (At least I think I jump to the end...same as whatever I'm doing now). Regexp and string dictionaries could be named differently (Call string dictionaries "Dictionaries" and regexp ones "Substitutions," or whatever), and colored differently in the list. Maybe throw in a disable dictionary button, so it'd still be associated with a game's profile, but not active.

                    Still no guarantee about profile ordering, however. Could make '*' first, and add another that would always be last. Not sure about letting profiles point to other profiles, or dictionaries point to other dictionaries. If I don't allow either, all I need is a 3 list display for profiles, dictionaries, and strings/regexps, and add and create dictionary buttons, order dictionary/regexp buttons, and panel to add new strings/regexps.

                    Problems with this: It's a hell of a lot more complicated than it currently is, particularly when it comes to ordering between strings and regexps, or stuff in different profiles. It'll involve a lot more code, and probably have a lot more bugs for quite a while.

                    Advantages: It's still easy to add strings, if that's what you want. Current stuff fits into the new framework with no change in behavior. It's powerful, and makes sharing of dictionaries between people, both global and for particular games, simpler than it is now. It's easier to reuse dictionaries only for particular profiles. Speed shouldn't be affected signficantly (Other than when using a lot of regexps), since won't have to switch between UTF8 and UTF16 much (I already to this once for each website you send a string to, so it's not like doing it a few times kills performance).
                    Last edited by ScumSuckingPig; 08-19-2010, 02:18 PM.

                    Comment


                    • I think that substitutions and dictionaries are completely different. Dictionaries are placed in the dictionaries directory and are in the EDICT format. Their content appears in a popup when you point with the mouse at a word. Substitutions are applied to the text when the text is inserted from the clipboard. I don't think that substitutions that contain strings should be called "dictionaries".

                      On the other hand every string becomes a regular expression if you escape all special characters in it. I don't see why they should be treated differently.
                      AGTH wiki

                      Comment


                      • Wow! *faints*...I don't heavily use regexes or substitutions so can't be sure, but i think that multiple fragmented dictionaries scenario like: strings->regexes->strings->regexes->strings->regexes is a bit overkill, because if you really want to insert some simple replacements in between regexes, that can be done in regexes as Stomp says (even escaping in most cases is not needed since TA mostly deals with japanese). Power of strings algorithm really shines with big lists and i can't imaging having multiple of those in one profile. So i think, two "dictionaries", one of each type, is enough for one profile. Also support the idea of splitting replacements to different files (it was already suggested here, i think), but maybe: "One profile - one file" principle is better than dispersing regexes and non-regexes to different files?
                        So, basically, i propose something like this:

                        Basic users just ignore "Regex" tab and work as before. Advanced users like Stomp just flip to "Regex" tab - appears similar list (or whatever editor) for regexes, and type in regexes or escaped strings. Who want to use both - use both. Seems like no advantages listed by you is lost...

                        Please, consider all above sceptically, since i tend to be carried away by my own delusions.
                        読んでみた。 読んでみようとした。 読めたらいいな、と思った。

                        Comment


                        • The problem with that is I really like the idea of being able to easily share dictionaries. Also like the idea of being able to use a dictionary in multiple games, but not all of them. Not a common need, but currently, it's not possible to do, without copying and pasting in a text editor.

                          Currently what I'm thinking of is basically that...with a few more options. Left pane is a profile list, with the same ordering as the dropdown (Easier to navigate than the dropdown, unless I more intelligently name profiles and implement autocomplete, which is a lot of effort). Second pane has, by default "Strings" (Or general), and Regexps, with entry counts. Other pane is the current list. Only additional complexity is you can, if you want, add secondary strings/regexp lists instead of just using the default two, and change their order.

                          A bit more complicated, but not *that* much more complicated, other than in terms of regexp/string ordering, and I don't have to worry about things like ordering of stuff within a profile, advantages of strings before regexps and vice versa, etc. The problem with ordering is that if I do strings second, and I ever feel like it, I can make an option to treat them as JParser/Mecab dictionary entries, and behavior is unchanged. Advantage of doing them first is that then if you want to do any reformatting of your current substitutions, then you can just make a regexp to do it, instead of messing with the original substitutions.

                          I'm really thinking of people just having one or two main dictionaries, and basically just one set of strings/regexps per profile...But having the ability to do more if they want to. Big problem with this approach is order of stuff in different profiles.

                          Anyways, probably be a couple weeks before I get to doing anything (Just came down sick today, was planning to get something working this weekend, but looks like it's not going to happen...And a bunch of new stuff is coming out soon - A couple books I want to read, a couple games, etc, so plenty of time to stew it over). Happy to talk it over in the meantime.
                          Last edited by ScumSuckingPig; 08-19-2010, 10:00 PM.

                          Comment


                          • All looks very nice, nothing to complain about here. Come to think of it now, i just suggested crippled version of the same thing. Also, nice to have a hope for "treat replacements as JParser/Mecab dictionary entries". I'm using one hacked TA version for that feature and another for english translations because errzotl80's replacements affects JParser/Mecab too.

                            Originally posted by ScumSuckingPig View Post
                            I'm really thinking of people just having one or two main dictionaries, and basically just one set of strings/regexps per profile...But having the ability to do more if they want to. Big problem with this approach is order of stuff in different profiles.
                            ??? Ability to have multiple dictionaries per profile eliminates the need for profiles like Windows\Explorer.exe or TA\Translation Aggregator.exe and with having first and last profiles, all order is under control...
                            Last edited by Setsumi; 08-20-2010, 12:14 AM.
                            読んでみた。 読んでみようとした。 読めたらいいな、と思った。

                            Comment


                            • Wow, lots of updates for TA and TAHelper. Great job guys.
                              I'm grateful now TAHelper can loading big names file very fast. And at last, TA can separating character between Hiragana and Katakana, now there will be no more misplacing "come" (いく) and "cum"(イク) word again, lol xD
                              But regarding to replacement ideas, it looks gonna changing after 0.4.3, I better wait and see first.

                              Comment


                              • Originally posted by Setsumi View Post
                                All looks very nice, nothing to complain about here. Come to think of it now, i just suggested crippled version of the same thing. Also, nice to have a hope for "treat replacements as JParser/Mecab dictionary entries". I'm using one hacked TA version for that feature and another for english translations because errzotl80's replacements affects JParser/Mecab too.

                                ??? Ability to have multiple dictionaries per profile eliminates the need for profiles like Windows\Explorer.exe or TA\Translation Aggregator.exe and with having first and last profiles, all order is under control...
                                Problem with that is I currently have no notion of source of text...So even if I remove the '*' profile, if there are still multiple games running...Anyways, that's something I eventually want to get around to implementing, too, once I start logging translations (Be a long time before I get around to that, most likely, however)

                                Comment

                                Working...
                                X