Am Mittwoch, 14. November 2012 um 21:47 schrieb jan iversen: > While programming the l10n translation, I have stumbled across something > which I do not know is a real or theoretical problem. I need an opinion > from people with more experience. > > Description of the current situation: > When you run configure with e.g. "--with-lang=da", all languages Are > inserted in the source files alongside with the original en-US text. This > works without problems > > BUT, if the developer forget to do a checkout (thereby removing the extra > languages) but does a commit, then SVN will have all languages in the file. > After the commit a snapshot (or development) build will contain all > languauges for that file. Note: If a translation changes, it will be > replaced in the file with the next build, so it will work. However: > - developer/snapshot contains an "unwanted" language part > - it is not clean that all language are in this file, as well as in the sdf > file (original), and can lead to confusion, where what is maintained. > > What I easily could do, was NOT to overwrite the file, but place a new file > (same content but with all languages added) in the <platform>/misc > directory, therefore the original would be left untouched. This requires of > course some makefile changes (the new l10n process requires anyhow > changes), which I will do (in a sub-branch) when the system is ready. > > Question: > > Is it a problem that the original is overwritten, and it would be better > to write a new file (in misc) ? > > or > > Am I thinking about a theoretical problem, that is no real world problem ? >
First of all sorry for the late response, I am still haven't read all mails after my vacation. I am not sure if I understand you correct but normally no originals are overwritten during the build. Files get merged in the local output directory and later used from there. Juergen > > Just to be sure, the effort of doing one or the other are the same, so that > is not an argument (at least for me), we should do what is correct. > > Jan I.
