tag:blogger.com,1999:blog-39045944427918019692024-02-20T12:14:21.938-08:00The Xlat ProjectUnknownnoreply@blogger.comBlogger59125tag:blogger.com,1999:blog-3904594442791801969.post-26202998432440244482014-10-23T11:33:00.001-07:002014-10-23T11:33:11.388-07:00TransTools for VisioNot terribly Perl-specific, obviously, but here's the first tool I've ever found to help with translating Visio documents and embeds: <a href="http://www.translatortools.net/visio-about.html">TransTools for Visio</a>. It's not perfect (what in the Microsoft ecosystem can ever be?) but it's a damn sight better than slogging through by hand, and a point of departure should I run into more Visio in the future. For some reason, it's sadly rare.<br />
<br />
As things stand, with Word 2003 and Visio 2007, translating in TRADOS 2011, the workflow is:<br />
<br />
<ul>
<li>Open the TransTools for Visio file in Visio.</li>
<li>Find a Visio drawing. If it opens directly, great, otherwise:</li>
<li>Cut and paste the drawing into a new document and open it directly there.</li>
<li>Select All and copy out everything in the drawing.</li>
<li>Paste into a new unnamed drawing in the same process as the open TTV drawing with the macros.</li>
<li>Run the magical macro to search the unnamed drawing and build a Word table.</li>
<li>Copy that table into a new document because the macro doesn't open the table in a full Word instance with menus (this could be fixed, obviously)</li>
<li>Drag that new document into the source language side of SDL.</li>
<li>Prepare that for translation.</li>
<li>Move to target language and translate. Don't use tabs, as they'll mess us up three steps from now.</li>
<li>Save the target document.</li>
<li>Open that document, select the left column, and paste into the original interim document, then copy the whole table.</li>
<li>Run the magical macro to search-and-replace the unnamed drawing. This uses a tab-delimited paste of the table, so tabs in your text will be Very Bad Indeed.</li>
<li>Select All in the unnamed drawing, and copy.</li>
<li>Delete everything in the embedded drawing, and paste the translated bits.</li>
<li>Jockey around to align properly. This is pretty manual. Sometimes you need to adjust text sizes as well, so actually this probably <i>has</i> to be manual.</li>
<li>If you copied the drawing out into a separate document, now copy it back in. Adjust for location and size if that step screwed things up, which they appear always to do (I don't have enough experience yet).</li>
</ul>
<div>
That's a pretty lengthy process, and yet it's <i>still</i> far superior in terms of mental capacity and quality control than not translating using a real tool. Everything except the translation and the last two steps could be automated, some during job preparation (which is obviously a good thing, because otherwise your word counts will be off).</div>
<div>
<br /></div>
<div>
So. Very nice tool.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-55526061426824024412014-07-06T13:40:00.000-07:002014-09-26T14:03:19.782-07:00Marpa or ParZu?I spent most of May working through my old natural-language tokenizer, adding a vocabulary-driven lexer/lexicon for German, all in preparation for undertaking a Marpa-based German parser. That's looking halfway decent at this point (except I need to do much better stemming), and then I decided to do a general search on German parsers and found <a href="https://github.com/rsennrich/parzu">ParZu</a>.<br />
<br />
The unusual thing about ParZu, among parsers especially, is that it's fully open source. That is, it has a free license, not a free-for-academics-only license - and it's hosted on GitHub. Also, I can try it <a href="http://kitt.cl.uzh.ch/kitt/parzu/">online</a>. So I fed it some more-or-less hairy sentences from my current translation in progress - and it parsed them perfectly.<br />
<br />
So here's the thing. I kind of want to do my own work and come to terms with the hairiness of things myself. And then on the other hand, parsing German by any means would allow me to jump ahead and maybe start doing translation-related tasks directly....<br />
<br />
It's a dilemma.<br />
<br />
<i>Update 2014-09-26:</i> Maybe not such a dilemma. ParZu is written in Prolog and I'm just not sure I'm up for that. It honestly seems it would be <i>easier</i> to do it in Marpa...<br />
<br />
This is probably incorrect. But I think I'm going to start finding out, this week.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-77480589266433930742014-06-08T04:18:00.003-07:002014-06-08T04:18:50.747-07:00Compiling corpiSo there's this <a href="http://homepages.inf.ed.ac.uk/pkoehn/publications/de-news/">German news corpus</a> obtained between 1996 and 2000 from online retrieval that I intend to use for some of my NLP work, and it occurred to me that I could build a similar corpus (well, the monolingual side of it, anyway) by doing my own periodic retrievals.<br />
<br />
To that end, here's the RSS feed pages for the <a href="http://www.sueddeutsche.de/service/updates-mit-rss-igoogle-netvibes-mein-yahoo-unsere-feeds-fuer-sie-ueberall-live-dabei-1.393950">Süddeutsche Zeitung</a>, the <a href="http://nol.hu/archivum/rss-2097">Népszabaság Online</a>, and the <a href="http://nepszava.com/feed">Népszava</a> (published in New York for Hungarian-Americans).Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-1110026414068802932014-06-08T04:11:00.004-07:002014-06-08T04:11:50.665-07:00Analysis of chemical namesTurns out the linguistic structure of chemical names is non-trivial. Unfortunately, as it's also quite profitable, it all seems to be behind paywalls, but I'm visiting Bloomington this summer and will have the opportunity to spend some time in the library, so this is one of the things I hope to make some headway on.<br />
<br />
In the meantime, here's a <a href="http://pubs.acs.org/doi/abs/10.1021/ci990062c">paywalled article</a> from the promisingly named Journal of Chemical Information and Modeling, which describes an early version of <a href="http://www.cambridgesoft.com/support/DesktopSupport/Documentation/N2S/index.htm">Name>Struct</a>, a closed-source interpreter for chemical names that strives to understand them in a way similar to a human chemist - that is, they attempt to model actual usage, not just reflect the official definitions of usage. Descriptive, not prescriptive, chemical linguistics.<br />
<br />
Anyway, the folks at CambridgeSoft who make Name>Struct have also highlighted some of the pitfalls of chemical linguistics <a href="http://www.cambridgesoft.com/support/DesktopSupport/Documentation/N2S/generalissues/index.htm">here</a>.<br />
<br />
Ah - silly me. A search on "Name>Struct open source" quickly returns <a href="http://pubs.acs.org/doi/abs/10.1021/ci100384d">OPSIN</a>, an open-source algorithm that I could probably adapt pretty easily. It's <a href="https://bitbucket.org/dan2097/opsin/">here at BitBucket</a>, and written in (shudder) Java. Nifty <a href="http://opsin.ch.cam.ac.uk/">Web interface here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-49524448497680900122014-04-28T11:58:00.000-07:002014-04-28T11:58:32.044-07:00TRADOS 2007 has an OLE dispatch APII wish I'd known <i>this</i> years ago! TRADOS TagEditor 2007 exposes an OLE API. Workbench doesn't appear to. SDL doesn't support it any more, either. But here are some references to it I ran across the other day. I'm going to try to dump the typelib soon (I have no time at all until Thursday).<br />
<br />
<ul>
<li><a href="http://marc.info/?l=perl-win32-users&m=107210226212560">This</a> - from Perl</li>
<li><a href="https://github.com/now/dot-work/blob/master/GHISLER/tools/work/ttx2x.wsf">This</a> from VB</li>
<li><a href="https://groups.yahoo.com/neo/groups/TW_users/conversations/topics/22799">This</a> from VB again.</li>
</ul>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-19256188534124951692014-04-18T15:37:00.004-07:002014-04-18T15:37:58.527-07:00GlobalSight and Microsoft TranslatorTwo links to software resources: GlobalSight is an open-source translation manager, and this <a href="http://www.microsoft.com/en-us/translator/for-translators.aspx">Microsoft Translator</a> page is probably a pretty decent definitive list of who to watch in the industry.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-21908284138101270622014-03-19T06:24:00.000-07:002014-03-19T06:24:00.478-07:00Vocabulary in EnglishI've been trying to find resources pertaining to the frequency of words in English - surely there must be some kind of graded scale of "commonness" or something? But so far I can't find anything that organized.<br />
<br />
Instead, I've got two interesting links here:<br />
<br />
<ul>
<li><a href="http://www.uefap.com/vocab/vocfram.htm">English for Academic Purposes</a></li>
<li><a href="http://img.sparknotes.com/content/testprep/pdf/sat.vocab.pdf">1000 most common SAT words</a></li>
</ul>
<div>
If we consider each of those and their ilk to be "general vocabulary words", then we'll have that much more luck in identifying technical content in a given document.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-32805041491592390492014-03-19T01:38:00.002-07:002014-03-19T01:38:06.097-07:00TaaS<a href="http://www.taas-project.eu/index.php?page=about-taas">Terminology as a Service</a>, as envisaged by the Europeans.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-47335344950012637792013-12-26T13:02:00.002-08:002013-12-26T13:02:36.630-08:00Terminology resourcesA bit of a linkdump here, first:<br />
<br />
<ul>
<li><a href="http://wordnet.princeton.edu/wordnet/download/current-version/">WordNet </a>is now at 3.0 on Unix, still 2.1 on Windows. The database from Linux is probably more useful. Interestingly, it's also available in Prolog. The licensing is pretty open these days. I don't think it used to be. That's welcome news.</li>
<li>Here's something called <a href="http://www.cs.brandeis.edu/~paulb/CoreLex/corelex.html">CoreLex</a>.</li>
<li>A good overview of the <a href="http://www.olif.net/documents/NewOLIFstruct&content.pdf">OLIF format</a>.</li>
</ul>
<div>
I think I could do worse for termbase storage in Perl than simply a database schema that mirrors OLIF (at least partly). That could be part of a general OLIF-handling set of modules. OLIF is attractive because it's model-agnostic in terms of how terms are conceptualized, so an OLIF-based module should be able to do something reasonable with essentially any terminological source.</div>
<div>
<br /></div>
<div>
Lingua::OLIF?</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-30421685113820730142013-05-04T15:06:00.001-07:002013-05-04T15:06:08.905-07:00TreeTaggerThe Perl module <a href="https://metacpan.org/module/Lingua::TreeTagger">Lingua::TreeTagger</a> provides an interface to the <a href="http://www.cis.uni-muenchen.de/~schmid/tools/TreeTagger/">TreeTagger program</a> (<a href="http://www.smo.uhi.ac.uk/~oduibhin/oideasra/interfaces/winttinterface.htm">Win installation</a> here). The only problem with TreeTagger is that it's got a commercial-license requirement. That, and the approach isn't good for Hungarian - but you can't have everything. This would probably be the best possible intermediate structure for frame-based translation, which I still think should be a valid approach.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-47070839121105278412013-04-27T04:30:00.001-07:002013-04-27T04:30:21.884-07:00Word listsI really need some kind of principled way to keep track of word lists and terminology. Ideally this would be a full-blown terminology management system with an online component and everything, but it would also be a word list source.<br />
<br />
Here are some good places to start with word lists:<br />
<br />
<ul>
<li><a href="http://wordlist.sourceforge.net/">http://wordlist.sourceforge.net/</a></li>
<li><a href="http://www.puzzlers.org/dokuwiki/doku.php?id=solving:wordlists:start">http://www.puzzlers.org/dokuwiki/doku.php?id=solving:wordlists:start</a></li>
</ul>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-69078946029328914982012-12-10T08:22:00.000-08:002012-12-10T08:22:08.086-08:00File::TMXI just started scratching the surface for TMX files. I'm going to end up with some generalized useful tools for XML files.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-49971386745987952602012-12-10T08:21:00.001-08:002012-12-10T08:21:09.338-08:00Terminology source: EMAThe <a href="http://www.emea.europa.eu/ema/index.jsp?curl=pages/medicines/human/medicines/000471/human_med_000619.jsp&mid=WC0b01ac058001d124">European Medicines Agency</a> publishes patient information about European-approved (not nationally approved) drugs in all the European languages. This would be a useful corpus for terminological (and syntactic) analysis.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-49621587430978151372012-10-17T12:36:00.003-07:002012-10-17T12:37:50.944-07:00OLIF<a href="http://www.olif.net/index.htm">Open Lexicon Interchange Format</a> (OLIF) is an XML terminology format that SDL Multiterm 2009 can import. (In other news, unlike the first time I bought them, TRADOS 2007 and Multiterm 2009 are now interoperable. Must have been an upgrade between then and when I bought this laptop. Bodes well for my everyday work!)<br />
<br />
So ... building on OLIF and my new SQP tool, maybe it's time to consider writing that terminology database thing with a nice Perly wrapper.<br />
<br />
By the way, OLIF was initially supported by SAP (and it's an SAP-related job I'm working on right now!) and the OLIF Consortium is like a who's-who of the big players in the translation industry. So it's probably worth grokking.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-52126664351927630402012-09-11T03:51:00.001-07:002012-09-11T03:51:21.233-07:00Translation of chemical names<br />
Here's a pretty fascinating <a href="http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2659868/">survey of chemical name translation</a> (I've been doing a lot of pharma translation this month). Turns out it's pretty tricky - looking at it, I'm not 100% sure it's as tricky as people make it out to be, because it's typical of language people that they find software magical, and typical of programmers to find natural language unreasonably hairy. But still - I think there's probably a (small) market for this kind of tool.<br />
<br />
<a href="http://semantic-programming.blogspot.hu/2012/09/translation-of-chemical-names.html">Cross-posted</a>.<br />
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-82852326966354778212012-06-15T12:40:00.002-07:002012-06-15T12:40:46.572-07:00Terminology from patent databasesIt should be relatively easy to automate a crawl of any patent database and extract terminology from the abstracts and translations of abstracts.<br />
<br />
Just a thought.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-89754810761768496832012-03-08T18:03:00.003-08:002012-03-08T18:23:30.512-08:00Terminology identification<span><span style="font-size: 100%;">On term extraction: I checked Okapi; they're just doing the same up-to-n-gram extraction I've always done and found wanting. Their English tokenizer is also comparable to mine (better tested, to be sure). So all in all, maybe I'm capable of doing competent work here. I need to do better testing, though.</span></span><div style="font-size: 100%;"><br /></div><div style="font-size: 100%;">But anyway, I figured maybe NLTK might have something more suited to my needs, so I searched on "NLTK term extraction" and came upon this <a href="http://groups.google.com/group/nltk-dev/browse_thread/thread/418f58d8b3ff5f22?pli=1">miscategorized post</a> on the topic at nltk-dev. That post led me to the Wikipedia page for <a href="http://en.wikipedia.org/wiki/Named_entity_recognition">named-entity recognition</a> (not so fantastically relevant but interesting nonetheless) and - gold - a suggestion to check Chapter 6 of <a href="http://nlp.stanford.edu/IR-book/information-retrieval-book.html">Manning, Ragavan, and Schütze</a> (which is one of the texts for the upcoming Stanford online NLP course, actually).</div><div style="font-family: Georgia, serif; font-size: 100%; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal; "><br /></div><div style="font-size: 100%;">Chapter 6 addresses term weighting. Finding relevant terms for indexing of documents is equivalent to finding interesting terms for terminology searches, and it turns out that the best way to weight terms is by <a href="http://nlp.stanford.edu/IR-book/html/htmledition/inverse-document-frequency-1.html">inverse document frequency</a>. (Which makes sense; clustering of terms in documents indicates that they're low-entropy and contain more information than, say, "the", whose inverse document frequency is 1.)</div><div style="font-size: 100%;"><br /></div><div style="font-size: 100%;">Long story short, a term in a document is interesting in proportion to the number of times it appears in the document and in inverse proportion to the number of documents in which it appears in a given relevant corpus. Given that my corpus is about five million words of translation memories, I have a good corpus, provided that I organize it into something document-like.</div><div style="font-size: 100%;"><br /></div><div style="font-size: 100%;">I'm going to consider a "document" to be each group of entries in the TM clustered by date. Since not all my translation goes through one TM, I can pretty much guarantee that all my work will be easy to cluster; from that I can derive an overall set of terminology for the entire corpus and calculate inverse document frequency for each term. From that, I can score each term found in a new document. If it's a known term for which I already have a gloss, I'm happy. If it's a new term with high relevance for which I have no gloss, I can research it. And if it's a known term for which I have no gloss, I can study my own corpus to try to extract a likely candidate for translation.</div><div style="font-size: 100%;"><br /></div><div style="font-size: 100%;">(This leads to a terminology extraction tool, too - working on both target and source languages and trying to correlate presence in segments, I'll bet I can come up with some pretty good guesses at glosses. Make that service a free one and you ought to do well.)</div><div style="font-size: 100%;"><br /></div><div style="font-size: 100%;">So I've got a pretty good plan for terminology identification at this point. Just have to find the time to implement it. Here's kind of the list of subtasks:</div><div><ul><li><span>Tool to convert Trados TM to TMX without my getting my hands dirty. I love Win32 scripting anyway - and this can run on the laptop for a day or two to chew its way through my five million words.</span></li><li><span>Do that TMX module for Perl.</span></li><li><span>For all my TMs, cluster the segments into "documents".</span></li><li><span>Polish up a terminology extraction tool (e.g. the same n-grams between stop words strategy I've used in the past).</span></li><li><span>Run said tool on the five million. Might want to do some kind of proper database and index at this point so I never have to do this again.</span></li><li><span>Calculate inverse document frequencies for everything.</span></li><li><span>Take a target TTX, extract terms, and classify them. This is the actual task.</span></li></ul></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-22703246441334569782012-02-29T20:00:00.003-08:002012-02-29T20:02:05.870-08:00Okapi<a href="http://www.opentag.com/okapi/wiki/index.php?title=Main_Page">Okapi</a> (Java) is a pretty comprehensive set of open-source tools to facilitate the translation process - including a simple workflow manager. (You can group sets of steps together to define your own processes, a technique I'm going to steal.)<div><br /></div><div>One more thing to take note of.</div><div><br /></div><div>Incidentally, its <a href="http://www.opentag.com/okapi/wiki/index.php?title=Main_Page">token types</a> are rather similar to the ones I've proposed.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-21102480889355267842012-02-13T11:30:00.000-08:002012-02-13T11:31:55.314-08:00Task: concordance-to-glossary toolI want to be able to look up one or more terms in a TM in the same way that concordances work now, then <i>make a decision</i> for a given document or customer, then have that decision checked globally. I'm most of the way to having this ready to go.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-87069381418566321402012-02-13T11:27:00.000-08:002012-02-13T11:32:09.799-08:00Task: find "actionable" terms in a given sourceThis is probably solved by NLTK somehow, but given a source text I want to be able to find probable glossary items to be researched and to be checked against a TM or glossary.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-35883219836001602822012-01-24T19:32:00.000-08:002012-01-24T19:34:20.573-08:00Task: Generalize File::XLIFF to work on zipped XLIFFThe files Lionbridge uses in their XLIFF editor are actually zipped XLIFF (with a .xlz extension) and include a "skeleton" file that seems to have some kind of information about placeables.<div><br /></div><div>It would be nice to have a way of dealing with those for batch manipulation (global find-and-replace, etc.).<span class="Apple-tab-span" style="white-space:pre"> </span></div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3904594442791801969.post-32633307426043557582012-01-07T19:45:00.000-08:002012-01-07T19:51:28.249-08:00OpenTag, TMX, and translation memory manipulationHere's an interesting thing: <a href="http://opentag.com/">opentag.com</a>, including the format definitions for TMX and a few other rather fascinating XML interchange formats (including one for segmentation rules!)<div><br /></div><div>I'm off onto a new tangent: a TMX manipulation module. I still don't have a fantastic API for it, but you know, I think I'm going to dump the xmlapi for real now. It's been 12 years now and I think it's time to move on. So I'm going to rewrite File::TTX to work with a different XML library (probably XML::Reader/XML::Writer) and do the same with TMX. This will allow me to choose between loading the file into memory in toto, or just writing a stream processor to filter things out on the fly for really large files.</div><div><br /></div><div>I envision an overarching Xlat::TM API that will work with File::TMX in specific, and perhaps with others if and when.</div>Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-3904594442791801969.post-79573677775986936852011-11-07T08:16:00.000-08:002011-11-07T08:24:46.565-08:00TRADOS XML noncompliantSo I'm working on a command-line utility for doing things with TTX files and ran into an unpleasantness: TTX files that are generated with the Word converter from Word documents with soft hyphens contain hex 0x1F values - but those values are illegal in XML. And when the XML standard says "illegal" they actually mean you're not supposed to call any parser that accepts them an XML parser.<div><br /></div><div>This is really quite dismaying - and I can only imagine the discussions that must have gone on at TRADOS when they clearly suborned this restriction in their XML parser. It would have been far cleaner from an XML standpoint to have translated soft hyphens into a tag - but that would have made the editing experience far less clean. So they were stuck.</div><div><br /></div><div>And now, I am too - I have to preprocess all TTX before passing it through the XML parser, which is a performance hit (which doesn't bother me too much) - but far worse, non-preprocessed TTX will infect the TM, so if I now make changes to the sanitized file and write it back out, it won't match the TM. This would be OK if we could be sure of sanitization before the TM were affected, but that's clearly too much to hope for in most real-world agency/freelancer workflows.</div><div><br /></div><div>It's also rather nasty that TMX dumps from an infected TM will also contain 0x1F characters - meaning non-TRADOS tools won't be able to parse those, either. And they <i>are</i> supposed to be interoperable.</div><div><br /></div><div>I think as a matter of policy I'm just going to sanitize and not worry overmuch about the rather small operability hit - at least until some actual project requires me to worry about it. Then I'll cross that bridge.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-57529632185643349682011-11-03T17:46:00.000-07:002011-11-03T17:47:14.197-07:00EnchantThe future of open source spelling may be <a href="http://www.abisource.com/projects/enchant/">Enchant</a>. There's no Perl binding. Yet.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3904594442791801969.post-74575794507939551652011-11-03T16:40:00.000-07:002011-11-03T17:47:52.294-07:00Text::Aspell on Win32 - non-trivial<a href="http://aspell.net/">Aspell</a> is the default open-source spell checking engine; its Perl binding is <a href="http://search.cpan.org/~hank/Text-Aspell/Aspell.pm">Text::Aspell</a>. The problem is that both Aspell and Text::Aspell are developed on Unix, and Things Are Different under Windows and MINGW32. Not insuperably different, but different enough that if you're the first person to try something, you'll live to regret it.<div><br /></div><div>OK. So, first things first; the <a href="http://aspell.net/win32/">W32 installation</a> of Aspell is back a release version but very stable. It doesn't actually have the include and library files bundled, but they're readily available - the problem being that W32 Aspell is developed with MSVC, and Strawberry Perl (my Perl of choice) compiles with MINGW32. Joy. So the library files are useless; we have to build our own. But let's make <i>include</i> and <i>lib</i> directories under Aspell.</div><div><br /></div><div>Now, we set environment variables: CPATH should point (at least) to the Aspell include directory and LIBRARY_PATH to the Aspell lib directory. Don't forget that your PATH should also include Aspell's bin directory - which will make it easier to use Aspell's command line tools for your dictionary maintenance anyway. So do it!</div><div><br /></div><div>Figuring out those environment variables, by the way, cost me about three hours. The remainder of the day was occupied with the next step: building a .DEF file that dlltool likes (some help was had from <a href="http://www.emmestech.com/moron_guides/moron1.html">this page</a> in remembering how a .DEF file is supposed to work), and then finding the appropriate combination of dlltool parameters. Turns out this:</div><div><pre> dlltool -d libaspell.defined --dllname aspell-15.dll<br /> --output-lib libaspell.a --kill-at</pre>is the <i>only</i> incantation that will work. Leaving out the --dllname, <i>even though it is specified in the .DEF file</i>, will cause linkage failures at runtime. Not helpful ones, either. This took me four hours, ultimately culminating in <a href="http://www.willus.com/mingw/yongweiwu_stdcall.html">this page</a>, which at least mentions the --dllname parameter.</div><div><br /></div><div>When dynamically linked, Aspell assumes the location of the DLL linked is either the root for dictionary searches or is in a 'bin' directory which is itself in the root for dictionary searches - in either case, the 'dict' directory of that root is where dictionaries should be. I had placed a local DLL in the Text::Aspell directory while flailing around; it took me half an hour to remember that.</div><div><br /></div><div>Anyway, I finally managed to get it running. Next step: extract words from a TTX to throw against it.</div><div><br /></div>Unknownnoreply@blogger.com0