Two implementations of website internationalization
Creating the translations table with an indefinite number of weirdly named columns is a bad idea. Subsequently adding a language will be awkward: it involves ALTERing the table, then a series of UPDATEs.

I suggest a table with normalization…

CREATE TABLE translations (
    id INTEGER NOT NULL,
    lang_id INTEGER NOT NULL,
    string VARCHAR(???),
    PRIMARY KEY (id, lang_id),
    FOREIGN KEY (lang_id) REFERENCES languages (id)
);


Then, for your programming convenience, create a view for each language that you support.

CREATE OR REPLACE VIEW en AS
    SELECT string
    FROM translations AS t
        JOIN languages AS l
            ON t.lang_id = l.id
    WHERE l.name = 'English';


Alternatively, define a stored procedure to satisfy your laziness.

That way, your schema stays normalized.  Adding a view is less risky than altering a table. Even your queries read better:

SELECT string FROM en WHERE id = ?;


However, for performance, I think you would be better off querying and caching all of the strings (probably a few hundred — no big deal) in PHP than issuing a separate query per string.