3 ms·
Since 70% of the files were xlf files used for translation/localization, couldn't they instead just store all of those in a single SQLite file and solve their p
by eigenvalue 3y ago
Since 70% of the files were xlf files used for translation/localization, couldn't they instead just store all of those in a single SQLite file and solve their problem much more easily? Any of the nuances of the directory structure could be captured in SQLite tables and relationships, and it would be easy to access them for edits by non-coders using a tool like DB Browser.
I feel like often people make problems much harder than they need to be by imposing arbitrary constraints on themselves that could be avoided if they approached the problem differently.
- Cthulhu_ 3y agoThat just sounds like adding another problem though. A filesystem (and git) already is a database, and plain files can be read and managed more easily than a possibly corruptible binary file. Plus, you'd lose history, unless you add more complexity to add history. I mean I don't know if they ever needed history but, just saying. You get certain things for free by using a filesystem / git.
- melx 3y agoYou commit the sqlite dump file(?) to git and have the history... I dunno but there are folks who would put anything in git. I work with someone who manages to exceed disk space of company's Gitlab instance by git adding everything. The disk is full again once a month.
- haizzz 3y agoThe translations are dependent on the original strings that is in code. For example if we change "design anything" to "design everything", the translations also needs to be updated to reflect that and by keeping it within vcs, we have an atomic change including both code, copy and translation. Moving it to a database would make updates easier but would now be a separate process to "sync" between copy change in code and translation changes in the database