Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault. |
Дата | |
Msg-id | 4608.1308602660@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault. (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault. Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault. |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut <peter_e@gmx.net> wrote: >> A better way might be that translators simply work on a clone of the >> source repository, which is then merged (as in, git merge) at release >> time. �There are some issues with that to figure out, but it sounds like >> the obviously right thing, from an interface point of view. > I don't think we want to track every single translation update as > commits in the main repository - we don't do that for non-translation > stuff... If it's a squash-merge, that's a different thing, of > course... > Other than that, yes, keeping translations in git branches seems like > a good interface. My recollection is that the current setup was created mainly so that translators wouldn't need to be given commit privileges on the main repo. Giving them a separate repo to work in might be all right, but of course whoever does the merges would have to be careful to only accept changes made to the .po files and not anything else. regards, tom lane
В списке pgsql-hackers по дате отправления: