well if you map it usually I have at least 2 because

id : value

the reason is pretty simple I like the numerical basis much more than the alphanumeric base esp as keys. and "delete from bla where key = 12" is easier to write than "delete form bla where key = 'this is my string'"

but on the other hand you could just use a json field with a key in modern databases :)

dev.mysql.com/doc/refman/5.7/en/json.html

postgresql.org/docs/9.3/static/functions-json.html

Depends really on the context. But its not bad. Its important not that you would prolly end up writing extra API end points for those tables in the long run though if you want to use that data in your UI.

For stuff like this, I typically have a single generic lookup table with at least four columns:

id, type, value, description

That way,

1, LANGUAGE, 1, English
2, LANGUAGE, 2, Spanish 
3, LANGUAGE, 3, Polish 
4, CITY, 1, Bangladesh 
5, CITY, 2, New York 
6, CITY, 3, Tokyo

... and so on

It's not bad a all, especially if it allows you to create more flexible queries. In my experience, I've found that single column tables can usually benefit from some additional metadata. It you consider US States, they could have their full name of just state code.

Even if you're using some a JSON blob, most database today support a JSON state type but then you'll benefit some additional columns that will let you quickly determine what it contains.

I prefer using JSON configs for small sets of data that will never change, like city names and their lat/lng.