Det vanligaste sättet jag har sett detta gjort är med två tabeller, membership och membership_ml , med en som lagrar basvärdena och ml-tabellen lagrar de lokaliserade strängarna. Detta liknar ditt andra alternativ. De flesta av systemen jag ser så här är gjorda på det sättet eftersom de inte var designade med internationalisering i åtanke från början, så de extra _ml-tabellerna "tackades på" senare.
Det jag tycker är ett bättre alternativ liknar ditt första alternativ, men lite annorlunda. Du skulle ha en central tabell för att lagra alla översättningar, men istället för att lägga in tabellnamnet och fältnamnet där, skulle du använda tokens och en central "Content"-tabell för att lagra alla översättningar. På så sätt kan du tvinga fram någon form av RI mellan tokens i bastabellen och översättningarna i innehållstabellen om du också vill.
Jag ställde faktiskt en fråga om just det här för ett tag sedan, så du kan ta en titt på det för mer information (istället för att klistra om schemaexemplen här).