You can consider them as value object, but you don't have to consider everything in DDD way.
According to Martin Fowler's definition:
When we use a Domain Model, we use it because it contains complicated
domain logic. It can be helpful the classify this domain logic into:
validations: checks that input makes sense and objects are properly
suited for further actions.
consequences: initiating some action that will change the state of the world
derivations: figuring out some
information based on information we already have
ValueObject s are good at validates and derivations.
Language tables, on the other hand, are usually used to solve i18n issues(ui/query conern). Generally speaking, there is no domain logic here.This kind of features are easily implemented in simple CRUD style and better for being so. Consider them in DDD add lots of constraints like only aggregates can be returned by the repository or you could only modify an local entity through it's aggregate. For example, Users edit a product, add english description and deutsch description. One can model product as an aggregate and description as value object, but this does not add much value and somtimes annoying(Now a product cannot be edited by a english editor and a deutsch editor at the same time for concurrent modification on an aggregate).
But what if there is some real domain validations and derivations on the product aggregate? like inventory and pricing. This is where bounded context comes to the play. One can have both an inventory/pricing bounded context modeled in DDD and a product description context modeled in CURD.