There is. It is on the printed page in front of me. The database had the text, all of it, and could not find it, because the text was filed under a different number.

This is a post about building a searchable corpus of Indian statutes and case law on my own machine, and about the fact that the dangerous failure is never the database that says nothing. It is the one that answers with confidence and is wrong.

I built it over several weeks with Claude. I made the decisions, ran everything on my own hardware, and checked the law myself; the scripts and most of the analysis came from the model. The mistakes are in here as well, because on a project of this shape the mistakes are the content. Nearly every genuine improvement came from something being printed to screen that looked wrong.

Why hold law locally at all

I am an advocate in Hyderabad. My practice is property, title due diligence, drafting. The work needs the text of statutes, rules, government orders and judgments, constantly, and mostly for a narrow set of jurisdictions: Central Acts, Telangana, and the Andhra Pradesh that Telangana inherited.

The obvious answer is a subscription database. They work. But two things pushed me the other way.

The first is cost and dependence. The second matters more: I cannot audit what I cannot see inside. When a subscription database returns nothing for a section, I have no way of knowing whether the section does not exist, or whether their ingestion mangled it the way mine mangled HMDA section 5. When my own corpus does that, I can go and look.

There is also a speed argument that turns out to be real. Searching a million judgments on my own machine takes about a second.

What the corpus is made of

The whole thing lives at D:AiTools on a Windows workstation, a Ryzen 9950X3D with 64 GB of RAM. The pipeline is deliberately dull: scrape original sources, convert to markdown, write parquet, query with DuckDB. No database server, no index server, nothing to keep running. Files on a disk.

An early decision shaped everything after it. There is a bulk dataset of Indian legislation on Hugging Face, and I downloaded it. Then I decided not to use it for statutes, and to scrape India Code and the Telangana Law Department fresh instead. Not because the dataset is bad, but because I wanted to know the provenance of every section I might cite, and to be able to go back to the page it came from. I kept the dataset to cross-check against, once.

What the Act surface holds today, counted this morning:

58,381 rows across eight parquet files

  India Code       828 Central Acts     35,390 sections
                   112 Telangana Acts    1,542 sections
  Telangana Law Dept   184 Acts
  Schedules            380 Acts          1,484 schedule rows
  Act-level PDFs       452 Acts
      196  Andhra Pradesh, pre-2014, applies in Telangana
      179  Telangana
       56  Andhra Pradesh, post-2014, residuary AP only
       18  Central
  Harvested G.O.s, circulars, orders   757 rows

Separately there is an index of my own prior work: 18,932 documents out of my OneDrive, read-only, so a search can turn up the deed I drafted in 2019 alongside the section it relied on.

That AP split is not decorative. Andhra Pradesh was bifurcated on 2 June 2014, and an AP Act from before that date still applies in Telangana while one from after it does not. Every result line says which, because an Act that does not apply is still an Act, and the distinction has to survive into whatever is filed.

Counting is not checking

Here is the mistake that reshaped how I check this corpus.

The corpus held the HMDA Act with 58 sections, numbered up to 58. That looks complete. It is not. Sections 5, 6 and 8 were absent, and their text was inside the row filed as section 9, a row that opens with the repeal of a 1988 water-rates ordinance and runs to 10,362 characters, having swallowed several sections that come before it.

The cause is visible on the printed page. HMDA prints its section headings as marginal notes, in a column beside the body text. Extract a text layer from that PDF and the headings interleave with the sentences, so 5. never begins a line, and a splitter looking for a number at the start of a line never sees one.

So I stopped trusting counts and audited numbering continuity instead: for every Act holding eight or more numbered sections, is the run of numbers unbroken?

When that ran, on 27 August 2026, it found 1,151 Acts with eight or more sections and 99 with a gap. Most gaps are honest: sections repealed, or omitted from the source. But in 38 of them the missing section’s heading was present inside another row. The text was in the corpus, filed under the wrong number.

Re-running the same audit today gives 1,158 Acts and 86 gaps. The difference is the repair described below.

The consequence is worth stating plainly. Full-text search reaches misfiled text without difficulty. It is a lookup by section number that fails, and it fails by reporting that a section does not exist when it does. That is the wrong direction to fail in.

repair.py, and five ways it nearly filed the wrong text

Recovering misfiled sections sounds simple: find the missing number used as a heading inside another row, cut from there to the next heading, file it under its own number.

It is not simple, and the first version was wrong in five separate ways. All five were found by running it in a sandbox and reading the output before it touched anything.

It missed the section it was written for. The heading pattern required text to continue on the same line. India Code prints 5. alone, with (1) There shall be... on the line below. HMDA section 5, the whole reason the script existed, did not match.

Cuts ran to the end of the host row. A recovered section 8 swallowed section 9 and everything after it. Cuts now end at the next heading of any number.

Footnotes were recovered as sections. 54. Section 43 substituted by Act No.11 of 1969 is a footnote. It looks exactly like a section heading.

Page-group rows were used as hosts. Where an Act could not be split reliably it is stored as page groups, which contain the entire text, so every number appears in them. Recovering from those produces nonsense.

The same number was recovered from six different rows of the Wealth-tax Act.

The gate that did most of the work is a structural one: a row can only have swallowed sections that precede it. So a recovered number must be lower than its host’s number and within 40 of it. Without that gate, the Greater Hyderabad Municipal Corporation Act “recovered” section 19 out of a row filed as section 687, which is a schedule of cycle-rickshaw fees.

Ungated, the pass proposed 34 Acts and 133 sections. Gated, it proposed 23 Acts and 49 sections, and the 23 rejected candidates each carry a stated reason.

Today repairs_acts.parquet holds 49 recovered sections across 23 Acts, each labelled with the row it was cut from and marked medium confidence. It never edits another script’s file. The recovered rows join the same glob the reader already reads.

A correction

An earlier note of mine recorded that the GHMC Act had “37 of 53 gaps recoverable”. That was wrong, and it came from a crude heading search with none of the gates above.

A properly gated pass recovers nothing from GHMC. Its numbering gaps are footnote markers and schedule item numbers, not missing sections. Today the audit still shows GHMC with 635 sections present and 52 numbers missing, and that is the correct answer: they were never sections.

I am recording the wrong figure as well as the right one because a corpus you cannot correct in public is a corpus nobody should trust, including you.

Heuristics that fail interestingly

Three gates keep schedules and tables out of the recovery pass, and each was calibrated against real documents.

Digit density. Statutory prose runs 3 to 4 per cent digits. Schedules run 24 per cent and up. The threshold sits at 18. This caught a recovered “section” of 247,454 characters that was the Telangana Panchayat Raj Act’s schedule of village names.

Line length. Text laid out as a table puts each field on its own line. Village schedules average 9 characters per line; statutory prose averages 75.

That second gate was first set at 28 characters, and it rejected HMDA sections 5 and 8. India Code wraps its prose at about 27, and a section that is a list of committee members has short lines. A threshold tuned on the wrong sample rejected precisely the sections the whole exercise existed to recover. Moved to 15, the pass went from 44 sections to 49, the five additions being HMDA sections 5 and 8, Telangana Municipalities section 32, and two sections of the Telangana State Private Universities Act.

Capture ratio. Any split that captures under 92 per cent of a document’s text is rejected in favour of page chunks. This exists because of a specific failure: an Act splitter applied to a Government Order treats the numbered list of earlier G.O.s it cites as the sections. G.O.Ms.No.59 came out as a single “section 4” holding 47 per cent of the document, with the abstract and the operative order silently gone. Instruments that are not Acts, Rules or Regulations are no longer split at all.

Fifty gigabytes of judgments, and what they do not carry

Judgments come from the open-india-law dataset: 63 parquet files, 53.7 GB. I hold all of them.

The indexed corpus covers the courts that matter to my practice:

  telangana        1,005,147 judgments
  andhra-pradesh     261,778
  supreme-court       37,014

Now the part that decides how you use this data. Metadata completeness, measured this morning:

  court            judgments    no citation   no judges
  telangana        1,005,147        100.0%       81.9%
  andhra-pradesh     261,778        100.0%       88.3%
  supreme-court       37,014          0.0%        0.0%

Every Supreme Court judgment carries a citation and a bench. Not one High Court judgment in over 1.26 million carries a citation. You get the text and the case number and nothing you can put in a plaint.

That is not a defect in the dataset so much as a fact about what is freely available, and it changes the workflow rather than ending it. The corpus is where I find the case and read the reasoning. The citation comes from elsewhere, and it comes before anything is filed.

The dates need care too. Telangana decision dates in this data run from 23 October 1952 to 27 December 2079. Twelve judgments are dated in the future. The year column in the Andhra Pradesh file tracks ingestion rather than decision and cannot be used for anything.

Which court binds

For a matter in Telangana, a Supreme Court judgment binds, the Telangana High Court binds, and the Andhra Pradesh High Court binds only for the period before bifurcation. Bombay and Madras are persuasive, and worth reading, and they are not the same thing. The distinction has to survive into the document.

The dataset splits along that line almost exactly, which was a pleasant surprise:

  telangana, decided before 01.01.2019          707,308
  andhra-pradesh, decided before 01.01.2019       1,011
  andhra-pradesh, decided 01.01.2019 onwards    259,200

The in_telangana file is the predecessor court’s whole corpus going back to 1952. The in_andhra-pradesh file is overwhelmingly the reconstituted court at Amaravati. So the default tier applies a date predicate to the AP file alone, and the binding tier comes to 1,043,172 judgments. Every result line is labelled BINDING or persuasive, and a binding search says on its face that the other High Courts were not searched.

This nearly went wrong in a way worth describing, because it is the most dangerous class of bug in the whole project.

DuckDB’s regexp_extract(string, pattern) returns the whole match, not the capture group. The build stored in_telangana_judgments where it meant telangana. Every comparison against a bare court name then failed silently. The effect was that 260,766 post-2019 Amaravati judgments sat in the binding tier, labelled BINDING, and the authority ranking collapsed to plain date order.

Nothing errored. Nothing looked broken. A one-argument mistake quietly relabelled persuasive authority as binding, which in a document going to court is exactly the sort of error you do not get to explain away. The build now passes the group index, and the reader normalises whatever form it finds, so a stale index cannot mislabel authority even if it is rebuilt wrongly.

Search without a search engine

The obvious way to search a million judgments is a full-text index. I could not use one, for a reason that is specific and worth explaining, because it shaped the design.

The environment Claude reaches my machine through is a small sandbox: 2 CPUs, 3 GB of RAM. My workstation reports 32 CPUs. A full scan of the 9.1 GB binding tier takes seconds on the workstation and over three minutes in the sandbox, which is past the timeout on a single call. DuckDB’s full-text extension cannot be installed in that sandbox at all: the proxy variable is malformed for its parser, and with the proxy unset there is no network.

So an index that needed the extension would have been unreadable by the one reader that most needed it. The answer was plain sorted parquet, built natively on the fast machine, read cheaply by anything.

Four files:

  cases.parquet      one row per judgment            0.05 GB
  text.parquet       chunks, sorted by case          4.24 GB
  vocab.parquet      words and their ids             0.10 GB
  postings.parquet   (token, case, chunk)            0.91 GB
                                            total    5.31 GB

Over 1,303,939 judgments, 15,057,895 distinct indexed words, and 397,445,969 postings.

Two calibration decisions matter more than the structure.

Minimum word length is 4, not 5. Sale, deed, gift, rent and lien all carry legal phrases. Three-letter words are lost, so lis pendens is found on pendens alone, which is fine because the rarer half of a phrase does the work.

The commonness cut is 10 per cent, not 1. Words appearing in more than that share of cases are not indexed, because indexing them costs enormously and narrows nothing. The first threshold chosen was 1 per cent. Measured against 17,684 Supreme Court cases:

  possession      5.3%
  registration    1.9%
  performance     1.8%
  adverse         1.6%
  injunction      1.1%
  mortgage        1.0%

A 1 per cent cut would have excluded every one of them. It would have produced a technically excellent index, of a corpus of property judgments, that could not search for possession, registration, performance, adverse or mortgage. Only 375 words are common enough to exclude at 10 per cent, and when a search hits one it is reported by name, so a search for “part performance” says it searched on performance alone.

Matching is by proximity, not merely co-occurrence. Postings carry the chunk as well as the case, so intersecting on chunk requires the words to fall within the same passage of roughly 2,000 characters. It does not prove the phrase appears in that order. It is much better than “both words are somewhere in this judgment”, and the phrase still has to be confirmed by reading.

Three performance facts

Row group size is the difference between a skip and a scan. At 50,000 rows per group, each group in text.parquet held about 80 MB of text, so fetching 200 scattered cases decompressed most of the file and took 29 seconds. At 1,000 rows a group is under a megabyte and the reader skips almost everything.

An IN-list of literals is pushed down; a JOIN is not. The same 200 lookups written as a join against a temporary table read the entire file: 0.1 seconds became over 40.

A warm cache lied to me twice. Verifying a phrase by reading the text costs about 20 seconds cold, however few cases it asks for, because a 4 GB store cannot stay resident in 3 GB of RAM. Two earlier measurements of 2.5 seconds were a warm cache, and they misled the design twice before the proximity approach removed the need to read text at query time at all.

Where it landed, on 2 threads:

  specific performance   1.02s   8,466 cases
  adverse possession     0.91s
  lis pendens            0.85s
  pattadar pass book     0.92s

Against over three minutes before any of this.

One further thing had to be designed rather than discovered. Ordering strictly by authority, a window on “specific performance” returned 400 Supreme Court cases and nothing at all from 11,429 Telangana candidates. Telangana is the court I appear before. Display slots are now shared between courts, allocated smallest tier first so slack flows onward.

What I still do not trust

A corpus is only as useful as its own account of where it is weak.

Two Central Acts cannot be completed from India Code. The Income-tax Act 1961 and the EPF Act 1952. India Code holds no Act-level PDF for them and only a fraction of the sections. Both are fetched separately.

The Hindu Succession (Andhra Pradesh Amendment) Act 1986 matters for coparcenary devolution before 9 September 2005, and the only copy I have is from PRS Legislative Research, which prints its own disclaimer that the text is unverified. It is deliberately kept off the Act surface and findable only in my own-work index. The real text has to come from the Law Department before it is cited.

Every HMDA document arrived over an unvalidated TLS connection. All 75 are stamped tls=unverified, because hmda.gov.in’s certificate chain does not validate. They are usable and they are flagged, and any one of them is checked against the browser copy before it is cited.

OCR misreads digits. 522 scanned PDFs, 6,738 pages, English and Telugu, banded 222 high confidence, 193 medium, 107 low. A document number came back as NO,P 2418/2013-14. Any survey number, extent or consideration taken from OCR text is checked against the original PDF. Results drawn from OCR print a warning saying so. And the opening pages of a registered deed are the stamp paper, which OCRs as ornament noise, so an OCR’d deed is judged by its body and not its first lines.

Some sources cannot be harvested at all. The CCLA site renders a page header and stops: viewActs.do, viewGO.do and viewCirculars.do each return two links and no table. That is not a selector problem, the pages are empty. And goir.telangana.gov.in is an ASP.NET WebForms application with view-state and cascading postbacks, where a result set only exists after a POST carrying the view-state the server has just issued. A listing-page harvester cannot touch it.

A naming rule learned the hard way. A document’s title becomes its act name, and lookups match that name loosely. A document titled “Registration Rules, Telangana — rules under the Registration Act, 1908” shadowed the Registration Act itself, so asking for section 49 of the Registration Act returned rule 49 instead of section 49, which is the provision on the effect of non-registration. A title must never contain another instrument’s name.

And one Act answers twice, by design. HMDA section 5 exists in the corpus in two forms: the Act as originally enacted, naming APIIC, APHB and APSRTC, hand-read by me from printed pages; and the India Code text as adapted for Telangana by G.O.Ms.No.45, Law (F) Department, dated 1 June 2016, naming TSIIC, the Telangana Housing Board and TSTRANSCO. Both are correct. For the composition of the Executive Committee as it stands today, the adapted text governs.

What this is actually for

It is not a product and I am not proposing that anyone else run one. It is a tool with a known shape, whose weaknesses are written down where I can see them, which answers in about a second, and which does not stop working if a subscription lapses or a website is redesigned.

The thing I did not expect was how much of the work would be auditing rather than building. The scraping was a weekend. The gates, the calibration, the gap analysis, the five defects in the recovery pass and the one-argument bug that mislabelled a quarter of a million judgments as binding — that was the actual project.

Which brings it back to HMDA section 5. It was in the corpus the whole time. The lesson is not that the pipeline was bad. It is that a lookup which answers “no such section” and a lookup which answers “here is section 5” can both be produced by a database that holds the same bytes, and the only thing standing between them is whether anyone checked.

Glossary

This post has two audiences, and each will find half of it obvious. The terms below are defined in the order they appear, on the assumption that no reader knows both halves.

Act surface — my term for the set of files a section lookup searches, as distinct from the full-text library. A document promoted to the Act surface can be asked for by section number. One left in the library can only be found by searching its words.

Parquet — a file format for storing tables in columns rather than rows, compressed, with statistics recorded for blocks of rows. A reader can consult those statistics and skip blocks that cannot contain what it wants, without decompressing them.

Row group — a block of rows inside a parquet file, and the unit that a reader skips or reads. Their size is a design decision, discussed above.

DuckDB — a database engine that runs inside your program rather than as a server, and reads parquet files directly from disk. No installation to maintain, no daemon running.

Predicate pushdown — the behaviour that makes the above work: the filter is handed down to the file reader so it can skip data, instead of the reader returning everything and the filter discarding most of it afterwards. An IN-list of literal values is pushed down. A join against another table generally is not.

Full-text index / FTS — the conventional machinery for searching text at speed, usually a database extension. Not used here, for the sandbox reasons set out above.

Vocabulary and postings — the two halves of any word index. The vocabulary maps each word to a number. The postings list records, for each word number, where it occurs. Searching is intersecting postings lists.

Posting — one entry in that list. Here each posting is a triple of word, case and chunk, which is what makes proximity matching possible.

Chunk — a passage of a judgment, roughly 2,000 characters. Judgments are stored in chunks so that “these two words appear in the same chunk” can stand in for “these two words appear near each other”.

Proximity matching — requiring search terms to fall within the same chunk, rather than merely somewhere in the same document. It does not prove the words appear as a phrase in that order.

MINLEN — the shortest word the index will store. Set to 4 here.

Commonness cut — the share of documents above which a word is too common to be worth indexing. Set to 10 per cent here, for the reasons measured above.

OCR — optical character recognition, deriving text from a scanned image. Reliable for prose, unreliable for digits, which is why numbers taken from OCR are checked against the original.

Text layer — the machine-readable text embedded in a PDF. A PDF produced from a word processor has a good one. A PDF that is a photograph of a page has none, and needs OCR.

Marginal note — a section heading printed in the margin beside the body text rather than above it. The cause of the HMDA failure: in the text layer the marginal notes interleave with the sentences.

Splitter — the code that divides a statute into its sections. Most of the failures described here are splitter failures.

Page group — the fallback when a document cannot be split reliably: it is stored as groups of pages, flagged as unsplit, rather than given section numbers that might be wrong.

Capture ratio — the proportion of a document’s text that a split accounts for. Below 92 per cent the split is rejected, so no document can silently lose text.

Digit density — the proportion of characters in a block that are digits. Prose runs 3 to 4 per cent, schedules 24 per cent and up.

Harvester — the script that fetches documents from government websites, driven by a manifest describing each source, rather than a separate scraper per site.

Manifest — the configuration file listing each source, its pages, and how to treat what it returns.

G.O. — Government Order. A departmental instrument. G.O.Ms. is an Ordinary Order; the number and date identify it.

India Code — the Government of India’s official repository of Central and State legislation.

Bifurcation — the division of Andhra Pradesh on 2 June 2014, creating Telangana. An Andhra Pradesh Act from before that date continues to apply in Telangana; one from after it does not.

Binding and persuasive — a judgment of a court above you in your own hierarchy binds. A judgment of a court of equal standing elsewhere is persuasive: worth reading, worth citing, but it does not compel a result.

Pattadar pass book — the Telangana land record document evidencing a cultivator’s rights. Used above as a search example because it is a phrase of exactly the shape this index handles well.

Coparcenary — in Hindu law, the body of family members who take an interest in ancestral property by birth. Relevant here because devolution before 9 September 2005 turns on statutory amendments that must be sourced accurately.

Sandbox — the constrained environment the AI assistant reaches my machine through: 2 CPUs, 3 GB of RAM, restricted network. Several design decisions exist only because of it.

TLS validation — the check that a website’s certificate chains to a trusted authority. tls=unverified on a stored document means the download was made without that check succeeding, and the document should be confirmed against the browser copy before it is relied upon.

The post The section that wasn’t there appeared first on Stubborn Fanatic - Tech Blog.

When I finally opened it, the server turned out to have been keeping a precise record of what happened.

I did the work over one evening with Claude, which matters to how this reads. I made the decisions and ran every command on my own server; the diagnosis, the scripts and several confident wrong turns came from the model. The wrong turns are in here too, because they were the useful part. Tech is a hobby for me. Law is what earns my living, and a fifteen-year-old broken WordPress had long since stopped being a thing I could justify an evening on. Having something that would grind through log files and SQL dumps without getting bored changed that arithmetic.

What the server was saying

The first question was whether anything was alive at all. The domain resolved to my DreamHost IP, same as my other sites, so DNS was fine. HTTPS failed on a certificate error. Over plain HTTP I got a 301 to the www hostname, then a 500 Internal Server Error with an empty response body.

An empty 500 is a particular kind of unhelpful. No error on the page, no stack trace, nothing to search for. It means PHP died before producing output, with display_errors off, which on a production host it should be.

The useful clue came from the access log rather than the error log:

2026-09-02 21:24:28   200   /favicon.ico

A 200. Static files were being served. That one line rules out most of what an empty 500 can mean. Apache was healthy, the virtual host was configured, the document root pointed at the right folder. Only PHP was dying.

Which meant anything on the site that was not PHP could still be read. So we asked for the file every WordPress install ships and nobody ever deletes:

curl http://techblog.viveksanghi.com/readme.html

Version 3.1.2
Semantic Personal Publishing Platform

WordPress 3.1.2, released April 2011.

The one-line cause

The error log had been recording the same entry for years:

[techblog.viveksanghi.com] [warn] mod_fcgid: stderr: PHP Parse error:
syntax error, unexpected token "new" in
/home/viveksanghi/techblog.viveksanghi.com/wp-settings.php on line 219

Line 219 of WordPress 3.1.2 reads:

$wp_the_query =& new WP_Query();

That =& is assignment by reference to a newly created object. It was correct in PHP 4, where objects were copied on assignment and the reference avoided the copy. PHP 5 made objects handle-based and the construction became pointless. It was deprecated in PHP 5.3 and removed in PHP 7.0.

Removed, not deprecated. In PHP 7 and later this is not a warning or a runtime error. It is a parse error. PHP refuses to compile the file, so nothing in it executes, no error handler runs, no output is produced, and Apache has nothing to return but a bare 500.

The site did not break from anything I did. It broke when DreamHost moved past PHP 5, and it has been serving 500s to search engines and bots ever since.

Could it be patched? The construction appears 252 times across WordPress core. PHP stops at the first one, but fixing that line only exposes the next. This is not a bug you repair. It is a language incompatibility, and the only answer is a newer WordPress.

The timestamp in the root directory

Sitting in the web root was a file called .maintenance, containing one line:

<?php $upgrading = 1309848013; ?>

WordPress writes that file when it begins a core update and deletes it when the update finishes. This one was never deleted.

That Unix timestamp is 05/07/2011, 06:40 UTC.

WordPress 3.2 was released on 04/07/2011. Alongside .maintenance were two directories in wp-content called wordpress-3.tmp and wordpress-31.tmp, the staging folders the updater uses while unpacking.

So: the day after 3.2 came out, I clicked update. It stalled. It left the lock file, the temp directories, and a site still running 3.1.2.

The lock file did no harm. WordPress ignores a .maintenance older than ten minutes, a sensible piece of defensive design and the reason the site kept serving afterwards. But it dates the incident to the minute.

What the logs cannot tell you is what the site looked like when it stopped.

It was running Grid Focus, a theme I had modified by hand over several years until not much of the original remained, with a stack of plugins I had chosen one at a time. The update took it down. I troubleshot for a while. Then life happened, and I lost interest the way you do when a thing stops being fun and starts being a chore.

So I let it sit. Somewhere between 2020 and 2022 I paid a freelancer on Fiverr to bring it back, and for a while it worked. That did not last either.

Both theme folders were still on the server when I finally went looking. grid_focus_public and gridfocus-v1.5.1b, sitting among fifty other themes I had collected and forgotten, exactly where I left them in 2011.

Five years of nobody noticing

The site did not go down in 2011. It went stale in 2011 and died some years later when PHP moved on. The first half is provable.

An old wp-dbmanager install had been taking weekly database backups and leaving them in wp-content. There were 134 of them, 2.7 GB in total, running from 29/05/2011 to 31/07/2016.

Comparing the oldest against the newest, by table:

techblog_..._20110612.sql   posts: 274,916 bytes   comments: 370,174 bytes
techblog_..._20160731.sql   posts: 274,916 bytes   comments: 370,174 bytes

Byte for byte identical. Not a single post or comment changed between June 2011 and July 2016. The blog stopped in 2011 and the backups kept copying the same corpse every Sunday until they stopped too.

But the dumps grew from 1.4 MB to 37 MB over those years. Something was expanding. Breaking the 2016 file down by table:

12,549,505  wp_usermeta
   370,174  wp_comments
   342,650  wp_options
   274,916  wp_posts
    79,785  wp_postmeta

Twelve and a half megabytes of user metadata against 275 KB of actual writing, reaching about 35 MB by the final backups. Open registration on an unpatched WordPress 3.1.2, and five years of bots signing up. The comments stayed clean, which I put down to Akismet and the captcha plugin, though I cannot prove that from the data. Nothing at all was guarding the registration form.

Ninety per cent of my database was junk accounts.

Deciding not to repair

Reviving the 3.1.2 install was never really available. There is no supported upgrade path across fifteen years, and the parse error fires before WordPress prints a byte, so I could not reach an admin screen to start one.

Rebuilding felt right for a less technical reason. The install carried 44 plugins and 51 themes. Among the plugins were disable-wordpress-core-update and disable-wordpress-plugin-updates, which explains a good deal about why it was still on 3.1.2. Copies of wordpress-28.zip through wordpress-284.zip sat in wp-content, publicly readable. There was a forum directory, empty, and two bbPress integration plugins pointing at it.

A WordPress 3.1.2 install had been exposed to the open internet for roughly eight years before PHP killed it, and that version has a long published list of vulnerabilities. There is an irony worth sitting with: the parse error that took the site down has probably been protecting it since about 2019.

So: current WordPress, content carried across, nothing else.

Getting the content out

The live database was reachable but not trustworthy, and I had 134 dumps provably unchanged since 2011. We took the last one and parsed it directly rather than restoring it anywhere.

Two things came out of that which looking at the site would never have shown.

The comments were duplicated. The table held 840. After normalising whitespace and stripping tags, only 606 were distinct. 234 were exact duplicates of another comment on the same post by the same author, each pair differing only in whether the
tags had survived:

id=7    2006-09-06 16:54   'Thanks for viewing my Blog. Well... I must say...'
id=505  2006-09-06 11:24   'Thanks for viewing my Blog. Well... I must say...'

The second copies sit in a contiguous block of IDs above 500. The database is called techblog_blogger and the install had a blogger-blogspot-redirect plugin. A Blogger import run twice in 2006, once preserving HTML and once stripping it. Twenty years, and I never noticed, because on the page a duplicate comment just looks like somebody posting twice.

The spam was not where anyone expected. Given the state of the usermeta table, the assumption was that comments would be full of pharma and casino links. A pattern search for the usual vocabulary returned zero matches. The volume by year decays the way real traffic does, 571 in 2006, 208 in 2007, then single and double digits as the blog went quiet, rather than flooding the way a farmed table does.

The first attempt to find spam scored comments by link density. On a blog about Blogger and WordPress hacks that is a terrible signal, and it flagged 43 comments, most of them my own replies containing four or five links to code examples. Claude had produced that heuristic, run it, looked at the output and thrown it away unprompted, which was the right call and not one I would have caught if it had not shown me the list.

The second pass went by author name and destination domain and found the real thing: thirteen keyword-anchor link drops, the kind where the author name is the product. “Mens Suit” linking to a suit retailer. “Website Design Atlanta”, three times. “beats for sale”. “laptop battery”. Short, on-topic enough, easy to approve by accident in 2010.

That left 593 comments, all genuine, threading intact.

There was also a post dated 26/12/2020 in a database dumped in 2016. A draft whose post_date carried a mistyped year, its post_modified correctly reading 27/12/2010. It had been sitting ten years in the future for a decade.

What the rehearsal caught

Rather than trust the import, we rehearsed it: MariaDB and WP-CLI in a throwaway container, the same WordPress version, a replica of the uploads folder, the real import file.

Every expected number came back right except one. Attachments came out as zero instead of eighteen.

The WordPress importer does not simply create attachment records. For each attachment it downloads the file from the URL in wp:attachment_url. In the container that URL was unreachable, so every attachment failed silently.

On a real server it is worse than a clean failure. The URL points at the site being restored, over HTTPS, at a moment when the certificate has not been issued. And if the download does succeed, it writes a second copy of every file beside the ones already sitting in wp-content/uploads.

The fix is to tell it not to:

wp import export.xml --authors=create --skip=attachment

and then register the files already on disk, in place:

find wp-content/uploads -type f \( -iname '*.jpg' -o -iname '*.gif' \) \
  | grep -vE -- '-[0-9]+x[0-9]+\.[A-Za-z]+$' \
  | while read -r f; do wp media import "$f" --skip-copy; done

The grep -v matters. Of 56 files in the uploads folder, 36 were WordPress’s own generated thumbnails. Without that filter every -150x150 crop becomes its own media library entry.

Nobody would have found this by reading the script. It appeared only by running the whole thing end to end against a real database.

Four ways the deploy script was wrong

This is the part I would not have predicted before the evening started. The script that rebuilt the site was written for me to paste into an SSH session, and it had to be fixed four times before it ran clean. Every failure was caught by the script’s own preflight, before anything on my server was touched.

getent does not exist on DreamHost’s shell. The DNS check used it. The script would have aborted in preflight with a confusing error. Replaced with a PHP lookup, since PHP is guaranteed present there.

pipefail and head do not mix. The script ran wp --info | head -3. head closes the pipe after three lines, wp gets SIGPIPE and exits 141, and set -o pipefail with set -e turns that into a silent abort. The three lines of output on my screen were the last thing the script printed before killing itself, and the failure looked like nothing at all.

A $ in a password. My admin password contained $4. Inside double quotes bash expands that as a positional parameter, which does not exist, and set -u correctly aborted. The config block now uses single quotes.

--raw wrote an undefined constant. This one actually reached my server. The script ran wp config set WP_AUTO_UPDATE_CORE minor --raw, which writes define('WP_AUTO_UPDATE_CORE', minor); without quotes. In PHP 8 an undefined constant is a fatal error, so WordPress could not load at all, and the script reported it as “cannot reach the database” — which was wrong and sent me looking in the wrong place.

There was a fifth, structural, caught before I ran anything: the original script tested the database connection after renaming my site directory. If the database had been unreachable, it would have moved my entire site aside and then died. That ordering was reversed so every destructive step sits behind a check that has already passed.

I record these because the honest version of “an AI helped me fix my site” includes the four times it handed me something broken. What made it work was not that the output was right first time. It was that each failure was cheap, legible, and caught before it cost anything.

The redirect loop I caused myself

With WordPress installed and content imported, the site returned a redirect loop. techblog.viveksanghi.com redirected to www.techblog.viveksanghi.com, which redirected straight back, forever.

We assumed the host was misconfigured. I opened a support ticket saying so. One command showed we were half wrong:

curl -sI http://techblog.viveksanghi.com/readme.html      → 301
curl -sI http://www.techblog.viveksanghi.com/readme.html  → 200 OK

A static file that exists on disk gets redirected at the bare hostname and served at www. That first redirect happens above .htaccess, in the host’s virtual host configuration, and nothing on my side could override it. That half was DreamHost’s, and they removed it inside a couple of hours when asked properly.

The second redirect was mine. Static files at www served fine and only WordPress-handled paths bounced. That is redirect_canonical doing its job, because siteurl and home were set to the bare hostname while the server was serving www. Each half behaved correctly. Together they were an infinite loop.

Testing a static file rather than the homepage is what separated them. On the homepage both redirects are in play and the trace tells you nothing about which layer owns which. I cancelled the first ticket and filed a more accurate one.

What I would tell someone with a site in this state

Test a static file first. Whether readme.html serves tells you in one request whether the web server is broken or only PHP is. Almost everything that followed came out of that one 200.

The error log is the whole answer, and it is not in the panel. The hosting control panel showed access logs and traffic graphs for days. The actual parse error, repeating identically for years, was in a file on disk.

Check whether your content changed before you value your backups. 134 weekly backups sound like excellent hygiene. Comparing the first against the last showed 134 copies of the same 2011 content, with only the spam growing. Backup count measures nothing.

Rehearse the restore. A throwaway database and a full dry run took under an hour and caught a defect that would have cost the entire media library, silently, with a success message.

Suspect your own configuration before your host’s. I was three quarters of the way to blaming DreamHost for a redirect loop I had created myself.

If you are working with a model, make it show you its output, not just its conclusions. Every one of the four script defects and the bad spam heuristic surfaced because something got printed and looked wrong. None of them surfaced from reading the code.

The site is back. Seventy-five posts, 17/04/2006 to 25/05/2011, and 593 comments, on WordPress 7.1 with a clean database and no plugins carried across.

Sixty-eight images in the older posts still point at photos1.blogger.com and the bp1 to bp3 hosts, which Google retired years ago. Those have been broken far longer than the site was, and there is nothing left to restore them from. I am inclined to leave them, with a note. A blog that ran from 2006 should be allowed to show its age somewhere.

The post A parse error, a stalled upgrade, and fifteen years of silence appeared first on Stubborn Fanatic - Tech Blog.

It’s been over a month and a half since I have been using ipad 2 (3g+wifi 64 GB) here in India. Thankfully I have a good wifi setup at home where I could use and update ipad after my work hours. ipad is an impressive device and very easy to use as well. Once you learn how to get your way around ipad’s app store, itunes etc you might actually end up spending more time on your ipad and less on your notebook.

I have found ipad to be a great device for almost all basic work such as browsing, sending emails. listening to music, watching movies, videos etc However it isn’t a great option for reading books, magazines etc. Long periods of reading on ipad are tiring for a couple of reasons:

1. Screen brightness causes eye fatigue
2. ipad is kind of heavy of holding in hand (esp while travelling and in bed) and reading for a long time
3. Lack of a single store or app for meeting all my book/magazine/newspaper reading requirements

However I’d still give ipad a very high score for all the other things that it can do. Below is a list of various apps I use regularly

Reading

Flipad
Zinio
Kindle
iBooks

News

CNN
NDTV
TOI (Times of India app)

Games

Trade Nations
Contract Killer
Can Knockdown
Overkill
tictac free

Video Player

Azul Media Player

File Transfer

USB Disk
Dropbox

Fitness

Dailyburn

Other Apps

Compass
Truphone
xmarks (bookmark synchronization)

Some of these apps esp the games contain in-app purchases and can be pretty addictive.

3G Usage

I have used BSNL 3G on my ipad and found it to be pretty impressive and fast. I had to cut up my regular SIM into a micro SIM and use it on ipad. However, BSNL now offers ipad plans (prepaid and postpaid). Unfortunately pre-paid SIMs for iPad are currently unavailable and post paid as only one plan i.e. Rs 999/- unlimited

Other players such as airtel, Tata Docomo etc do not seem to have any inexpensive data plans for 3g. I hope they come out with some good competitive plans for 3G data users.

The post ipad 2 – My App List and usage in India appeared first on Stubborn Fanatic - Tech Blog.

1. It allows users to log in via multiple sites such as Twitter, Facebook, Open Id, Yahoo and Disqus itself

2. It allows users to track all their comments made across multiple sites, at a single place

3. When users manage their comments through Disqus and / or log into Disqus via one of their social networking accounts, the comment they make also gets published in their social networking feed resulting in greater propagation of the source post where the comment was made

4. Incredibly easy and smooth integration with wordpress

The post Disqus Comment System for WordPress appeared first on Stubborn Fanatic - Tech Blog.

Recently I learnt about a forum software by name bbpress which can integrate well with wordpress blogs. I decided to squeeze time out of my schedule to try this software and write about it.

bbPress is a very easy to use forum or bulletin board software from the creators of wordpress. To quote their website:

“bbPress is focused on web standards, ease of use, ease of integration, and speed. We’re keeping things as small and light as possible while still allowing for great add-on features through our extensive plugin system.”

This article will cover installation of bbpress for a wordpress blog and its deep integration with wordpress blog such that the blog and the forum share common logins, cookies and user databases. Make a note of the versions used before you proceed to read the installation/integration tutorial:

bbPress version: 1.0.2
Wordpress version: 2.8.9

bbPress download and server setup

– As a first step you need to download bbpress from here. Unzip and rename the folder to what ever you like. Whatever name you choose will also become a part of your forum URL in the following format:

<wordpress blog URL>/<bbPress folder name>

– Now upload this folder under you main wordpress directory on the server where you are hosting your blog. For example, I had renamed my bbPress directory to “forum” and uploaded it under the folder techblog.viveksanghi.com on the webserver such that my forum url become:

https://techblog.viveksanghi.com/forum

WordPress Setup

bbPress Integration Plugin

– Now login into you wordpress admin panel, install the plugin bbpress integration into wordpress and activate the plugin. On the plugin’s configuration page enter the URL of your bbpress forum which will be in the following format as already explained earlier:

<yourblog URL>/<bbpress folder name>.

Do not change anything else and hit the save button. Scroll down on the same page and you will be shown some code that you need to enter into your wordpress config file. Make a note of this code as we will require it in the next step.

WordPress Config

– Apart from the above-mentioned piece of code from the previous step, there are some additional changes that you need to make to your wordpress config file. Let’s looks are what additions are to be made to the wordpress configuration file. Download and edit your wordpress config file. This will be located under your main wordpress folder by the name wp-config.php

You have to enter the following values in the wp-config.php file:

AUTH_KEY
SECURE_AUTH_KEY
LOGGED_IN_KEY

Go here to generate complex keys for the above mentioned items. Then paste these keys in the wp-config.php file as shown below:

Also paste the code we generated earlier from the bbpress integration plugin of wordpress as shown in the image above.

Now its time to start your bbPress installation. However make sure to have the following details about your wordpress database handy as we will use the same database for wordpress and bbpress.

– WordPress database name
– WordPress database hostname (Note that it will not be “localhost” if you are hosting on dreamhost or other such hosting site)
– WordPress database username
– WordPress database password
– WordPress table prefix

In case you are new to using databases and/or are not sure where to find the above mentioned details, then you might want to install the WP-DBManager plugin in wordpress and should be able to view all these above details from within wordpress.

Once these details are ready, you may start the installation by proceeding to the following link:

[your bbPress forum URL]/bb-admin/options-wordpress.php

Step 1 – Database configuration

First you will be presented with the following screen:

Now enter the database details you collated earlier, as shown in the image below. You may also use the question mark symbols to learn more about each of these fields.

And then proceed to step 2.

Step 2 – WordPress Integration Settings

To fill in the details required for step 2, load the options screen of your wordpress blog using the following link:

[wordpress link]/wp-admin/options.php

On the bbpress installation page check integration and cookie integration settings as shown in the image. Now add the auth cookie, secure auth cookie and logged in key values (we created these values earlier before starting installation of bbpress) from the wp-config.php file. The salt values will be available from the wordpress options screen we loaded a while ago.

If you do not find the secure auth cookie salt value, you may leave it blank and it should not be a problem. Then scroll down and also check user database integration settings. Fill in the values from the database values that you noted earlier. Most of you will only require the wordpress database table prefix. Now save the integration settings and you will be prompted to proceed to step three.

Step 3 – Site settings

Fill in a name for your forum and the site URL as shown below. Site URL will depend on the folder name you gave to the bbpress folder before uploading it under wordpress folder.

Select the wordpress admin name from the drop down as the bbpress keymaster unless you wish to alot this supreme role to anyone else. Give a name for your first forum, then hit the save site settings button and you should be ready to proceed to your forum page.

Now go to the admin panel of your forum and select wordpress integration under the settings tab as shown in the image below.  Here you have to map user roles between wordpress and bbPress users as the user list is now synchronized and/or common between the two.

Once you save these settings, your wordpress and bbPress will be integrated and you are ready to go.

I am also planning to research into a system/plugin such that the wordpress posts become topics and the comments on each wordpress post become forum posts under these topics. If I find out some thing on these lines, I will definitely update this post or create a second post on this topic.

References: I researched the bbPress forums extensively and did a lot of hands on tinkering to learn how to install bbPress and integrate it with wordpress. This link was particularly helpful in my learning process.

The post bbPress: Installation and Deep Integration with WordPress appeared first on Stubborn Fanatic - Tech Blog.

In this article I will explain how you can:

1. Blog on a custom domain (eg. www.<yourname>.com) while not having to buy any hosting space on the web (Will cover both Blogger and WordPress)

2. Blog on a custom domain while also having custom hosting (Will cover only wordpress and explain how to migrate blogger blogs to custom/self-hosted wordpress)

I understand that many readers may question the need for this article when there are plenty or articles on the web. However I will try to make it very simple and easy to follow with judicious use of screenshots to make life simple.

Before proceeding, let’s note that one can always start of a free blog on popular blogging platforms like Google’s Blogger or WordPress. The URL of a blog on these free services will be like:

<example>.blogspot.com

<example>.wordpress.com

If you are new to blogging, I recommend that you first try out hosting via these free platforms and see if you are able to maintain a good posting frequency. Once seasoned, go ahead and buy web hosting etc and host the blog by yourself.

Blog on a custom domain (eg. www.<yourname>.com) while not having to buy any hosting space on the web (Will cover both Blogger and WordPress)

If you have a blog on Blogger or WordPress.com, you might be pleased to know that both these platforms allow you to buy a custom domain name and make that the URL address of your blog.

Blogger

1. To view the custom domain settings facility in your blogger account, just go to the settings -> publishing area as shown in the image above (expand image to read the instructions or just follow the on screen instructions in your account. It’s very easy!)

2. If you choose to buy a domain from Google, use this page as shown in the image above (read the price and the time period for which you are paying very carefully). As of now Google is using godaddy.com as partner for the domain name registrations and is also providing Google Apps on the domain. Which probably means you can have an email address like <yourname>@<yourdomain>.com .

3. However, if you have already bought a domain elsewhere, then click on the “Switch to advanced settings” link. You will be present with a page which looks like this:

4. Click on the link “setup instructions” and read it very carefully before you proceed with this step. You will have to create a CNAME (Canonical Name) record. This will make your domain point to Google’s servers such that when someone visits your domain, the request is forwarded to Google servers and they can fetch the appropriate blog (i.e. your blogspot blog) and display it to the visitor.

Blogger help provides specific instructions on setting up CNAME for certain domain providers. If you do not plan to buy your domain from Google and then I recommend buying it from one of the service providers listed on that page.

This step can be troublesome and you may feel free to contact me if you need any assistance. However note that I may be slow in responding and the real fun is in trying it out on your own

5. Once everything is done, enter the word verification and save your settings. Give it some time and then your blog will start working on your custom domain URL. Your old blogspot address will automatically redirect to your new custom domain.

As always, if you face problems, you may redirect your questions to me and I will direct you in the right direction

WordPress

If you have not already purchased a domain, then just like Blogger, wordpress also allows you to purchase a domain + redirect your wordpress.com blog to it for USD 15.00 (on this date).

You can also have your custom email by using Google apps on this newly purchased domain (learn more)

Buy a domain from wordpress and use it for your wordpress.com blog

1. Go to the “domains” section under “upgrades” on your wordpress.com dashboard (See the image).

2. On the page that appears, enter the domain you wish to use for your blog and click on “Add Domain to Blog” button (See the image below). A page will appear asking you to buy 15 credits to complete this transaction (unless you already have credits in your account). Note that you must have a Paypal account to purchase credits (currently 1 credit = USD 1.00).

3. Then you have to make sure (refer to the image below) that your newly purchased domain is recognized as your blog URL on the “domains” page and your wordpress.com blog redirects to your custom domain (also called domain mapping).

That’s it. You are ready.

You might want to learn more about managing domains purchased through wordpress.

Using your separately purchased domain for your wordpress.com blog

1. Visit this link and setup your domain to be used in wordpress domain mapping process. All you have to do is add the nameservers shown there to your domain. Remove any existing nameservers from your domain.

2. Once your domain is ready go to the “domains” section under upgrades, on your wordpress.com dashboard. Enter the domain name you wish to use as shown in the image above and click on the “Add Domain to Blog” button. If your nameservers are set correctly and have propagated, then WordPress will allow you to buy 10 credits to enable this domain mapping.

3. Now go to step 3 in the previous section (above) and you will be ready

If you ever have any problems regarding domain mapping, please do visit this link to seek help.

Alternate way to buy WordPress credits

Log into your wordpress.com account go to the gifts section under upgrades as shown in the image below:

While this page will allow you to gift the credits to other wordpress users, you may simply use it to purchase credits for your wordpress.com account.

I hope this article will make life simpler for everybody who is new to blogging platforms. Stay tuned for my next article where I will talk about having a blog on a custom domain with custom hosting.

The post Blogging on custom domains using Blogger and WordPress with and without self hosting appeared first on Stubborn Fanatic - Tech Blog.

I have successfully redirected stubborn-fanatic.blogspot.com to techblog.viveksanghi.com. The new home for this blog.

Those of you who were looking at my blogspot template for design ideas will be unable to do so any more. However I can send you my blogspot template’s full code for a nominal payment of $20 via paypal only. If you are interested, please contact me using this link for further instructions.

The post Welcome to the new location of Stubborn Fanatic appeared first on Stubborn Fanatic - Tech Blog.

Contest Info: There are 31 participating web sites, with the sponsorship of HP where HP is working with them to offer 31 prize packages – one a day for 31 days during a period from 09 May through 08 June 2008. Here are the details of the price package (which btw is worth well over USD 5000 in retail value):

• Display: 20.1″ diagonal WUXGA High-Definition HP Ultra Brightview Widescreen (1920×1200)
• Operating system: Windows Vista Ultimate (64-bit)
• Processor: Intel Core2 Extreme Processor X9000 (2.80GHz, 6MB L2 Cache, 800MHz FSB)
• Memory: 4GB DDR2 System Memory (2 Dimm)
• Graphics Card: 512MB NVIDIA GeForce 8800M GTS
• Personalization: HP Imprint Finish (Dragon) + Fingerprint Reader + Webcam + Microphone
• Networking: Intel(R) PRO/Wireless 4965AGN Network Connection and Bluetooth(TM)
• Hard Drive: 500GB 5400RPM SATA Dual Hard Drive (250GB x 2)
• Optical: Blu-Ray ROM with SuperMulti DVD+/-R/RW Double Layer
• TV & Entertainment Experience: Integrated HP HDTV Hybrid TV Tuner and 4 Altec Lansing speakers + the HP Triple Bass Reflex subwoofer
• Primary Battery: 9 Cell Lithium Ion Battery
• Productivity Applications: Microsoft Office 2007, Corel PaintShop Pro Photo X2, Corel Painter 4, Ulead VideoStudio 11.5 Plus
• Games: Viva Pinata, Microsoft Flight Simulator X, Microsoft Flight Simulator X Acceleration Expansion Pack, Gear of War
• Blu-Ray movies: The Pirates of the Caribbean Trilogy – The Curse of the Black Pearl, Dead Man’s Chest, At World’s End.

And here is a list of websites that are running/will run a seven day contest between the following dates (begin – end):

13 May – 20 May www.geekstogo.com
14 May – 21 May bink.nu
15 May – 22 May www.mediablab.com
16 May – 23 May www.last100.com
17 May – 24 May www.labnol.org
18 May – 25 May www.notebooks.com
19 May – 26 May www.slashdotreview.com
20 May – 27 May www.neowin.net
21 May – 28 May www.geek.com
22 May – 29 Mau www.lockergnome.com
23 May – 30 May www.planetx64.com
24 May – 31 May www.thegreenbutton.com
25 May – 01 Jun www.istartedsomething.com
26 May – 02 Jun www.bleepingcomputer.com
27 May – 03 Jun www.hardwaregeeks.com
28 May – 04 Jun www.geeknewscentral.com
29 May – 05 Jun www.geekzone.co.nz
30 May – 06 Jun www.thetabletpc.net
31 May – 07 Jun www.gearlive.com
01 Jun – 08 Jun www.gottabemobile.com

Some of the website site where the winners have already been declared are:

02 May – 09 May www.absolutevista.com
03 May – 10 May www.arstechnica.com
04 May – 11 May www.osnn.net
05 May – 12 May www.jkontherun.com
06 May – 13 May digitalmediaphile.wordpress.com
07 May – 14 May www.bostonpocketpc.com
08 May – 15 May www.the-gadgeteer.com
09 May – 16 May www.thedigitallifestyle.com
10 May – 17 May www.digitalhomethoughts.com
11 May – 18 May www.windows-now.com
12 May – 19 May www.windowsconnected.com

So I suggest you to head over to these website and track them to win the super prize package. For details about the contest please visit here. There is an RSS link and an OPML available so that you can track these sites conveniently.

In addition, most of these site have very good articles which techies and computer enthusiasts will definitely like. So go now and start participating, I am also competing

The post Contest Suggestion: 31 Days of the Dragon appeared first on Stubborn Fanatic - Tech Blog.

The post Poll result appeared first on Stubborn Fanatic - Tech Blog.

This is my first add-on goody for the year 2007. Hope you will like it. Brainiac came up with a suggestion to add more languages to my Google translate for posts hack. As the number of languages provided by Google is limited, I decided to use the BabelFish code, offered in a language translation widget by Amit Agarwal of Digital Inspiration. I have been using this hack in the “Translate” section of my navigational bar (at the top of the page).

– This code offers 14 languages, to which your readers will be able to translate your posts.
– There is also some translation code that Spanish Bloggers can use to allow their readers to read their blogs in English, French, Russian, German and Italian.
(See comments for credits)

I have modified that code so that you can use it in your post footers and allow your readers to translate individual posts (if they like). To learn how to add some thing to your template’s post footers, visit this page.

Update: Added code for English to Trukish courtesy emrex

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_nl"' title='Nederlands/Dutch'><img alt='Nederlands/Dutch' height='20' src='http://photos1.blogger.com/blogger/3709/485/400/nl.gif' width='30'/> Nederlands</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_fr"' title='Français/French'><img alt='Français/French' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539949_e76af75976.jpg' width='30'/> Français</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_ru"' title='Русский/Russian'><img alt='Русский/Russian' height='20' src='http://photos1.blogger.com/blogger/3709/485/1600/ru.gif' width='30'/> Русский</a> |
    
<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_de"' title='Deutsch/German'><img alt='Deutsch/German' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539933_041ca1eda2.jpg' width='30'/> Deutsch</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_it"' title='Italiano/Italian'><img alt='Italiano/Italian' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539953_0384ccecf9.jpg' width='30'/> Italiano</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_pt"' title='Português/Portuguese'><img alt='Português/Portuguese' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539966_0d09b410b5.jpg' width='30'/> Português</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_es"' title='Español/Spanish'><img alt='Español/Spanish' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539946_2fabed0dbf.jpg' width='30'/>Español</a> |

<a expr:href='"http://translate.google.com/translate?hl=ar&amp;ie=UTF-8&oe=UTF-8&langpair=en|ar&u=" + data:post.url' title='العربية/Arabic'><img alt='العربية/Arabic' border='0' height='20' src='http://www.google.com/images/flags/sa_flag.gif' width='30'/> العربية</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_el"' title='Ελληνικά/Greek'><img alt='Ελληνικά/Greek' height='20' src='http://photos1.blogger.com/blogger/3709/485/1600/el.gif' width='30'/> Ελληνικά</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_ja"' title='日本語/Japanese'><img alt='Japanese' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539955_925e6683c8.jpg' width='30'/> 日本語</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_ko"' title='한국어/Korean'><img alt='Korean' height='20' src='http://photos1.blogger.com/img/43/1633/320/13539958_3c3b482c95.jpg' width='30'/> 한국어</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_zh"' title='汉语简化了/Chinese Simplified'><img alt='Chinese Simplified' height='20' src='http://photos1.blogger.com/img/43/1633/320/14324441_5ca5ce3423.jpg' width='30'/> 汉语简化了</a> |

<a expr:href='"http://66.94.231.168/babelfish/translate_url_content?trurl=" + data:post.url + "&amp;lp=en_zt"' title='中國傳統/Chinese Traditional'><img alt='Chinese Traditional' height='20' src='http://photos1.blogger.com/blogger/3709/485/400/zh_tw.gif' width='30'/> 中國傳統</a>

Update: Added code for English to Trukish
<a expr:href='"http://babel.gts-translation.com/geturl?direction=50&amp;input_url=" + data:post.url' title='Türkçe/Turkish'><img src='[Image not available]' alt='Turkish' height='20' width='30'/>Türkçe</a>

Update: Some translate links for Spanish bloggers (based on a wordpress plugin pointed out by brainiac):

<a expr:href='"http://world.altavista.com/babelfish/trurl_pagecontent?url=" + data:post.url + "&amp;lp=es_en"' title='Spanish to English'><img src='http://bp0.blogger.com/_XGtsagQTuUQ/RZk8DP2JNiI/AAAAAAAAADk/eRxHS5s1f10/s320/english.jpg' alt='Eng' /> English</a>

<a expr:href='"http://www1.worldlingo.com/SH0gfCf2o9dM33sw2faPEI,6sc5M9NFT0/translation?wl_url=" + data:post.url + "&amp;wl_srclang=ES&amp;wl_trglang=fr" title='Spanish to French'><img src='http://bp1.blogger.com/_XGtsagQTuUQ/RZk8Df2JNjI/AAAAAAAAADs/jL1jKBhgKFc/s320/france.gif' />Français</a>

<a expr:href='"http://www1.worldlingo.com/SH0gfCf2o9dM33sw2faPEI,6sc5M9NFT0/translation?wl_url=" + data:post.url + "&amp;wl_srclang=ES&amp;wl_trglang=de"' title='Spanish to German'><img src='http://bp1.blogger.com/_XGtsagQTuUQ/RZk8Df2JNkI/AAAAAAAAAD0/JubAGPyc5d4/s320/germany.gif' />Deutsch</a>

<a expr:href='"http://www1.worldlingo.com/SH0gfCf2o9dM33sw2faPEI,6sc5M9NFT0/translation?wl_url=" + data:post.url + "&amp;wl_srclang=ES&amp;wl_trglang=it"' title='Spanish to Italian'><img src='http://bp3.blogger.com/_XGtsagQTuUQ/RZk8Q_2JNmI/AAAAAAAAAEE/pJodrosGp8I/s320/italy.gif' />Italiano</a>

<a expr:href='"http://www1.worldlingo.com/SH0gfCf2o9dM33sw2faPEI,6sc5M9NFT0/translation?wl_url=" + data:post.url + "&amp;wl_srclang=ES&amp;wl_trglang=ru"' title='Spanish to Russian'><img src='http://bp0.blogger.com/_XGtsagQTuUQ/RZk8RP2JNpI/AAAAAAAAAEc/Tnq_uTX3WhY/s320/russia.gif' />Русский</a>

If you want to display only the flag images, simply delete the text between the img tag and the </a> tag. In case you want to have only the text, remove the img tag completely. As always, don’t forget to make a backup of your template before applying this code.

Please drop a line here if you find some bug or if some thing doesn’t work. I have not tested out most of the code.

Also, Deniz of imessengr is now offering a modded three-column Thisaway template loaded with popular hacks. Visit his page to learn more and download the template.

The post Translate your posts into 14 languages (Updates added) appeared first on Stubborn Fanatic - Tech Blog.