Hi Ãvar, Ãvar ArnfjÃrà Bjarmason writes: > Â* I don't want people to *have* to use any one interface. > Â* Any way of editing the translations will have to comply with git's > Ânormal patch submission process. Thanks for the detailed response. The way I see it, major changes are required in two distinct areas: 1. The way the user interacts with the web-based UI. In the current UI (of Transifex), everything is one continuous stream; everything is auto-saved, and the user makes no indication of a logical change. This has to be changed to enforce creation of commit messages for the Git project: without a valid commit message and signoff, the translations are essentially useless. Also, authorship information isn't available -- so, the user accounts should have a way to keep this information, and the Git project should be able to demand that this information is available. 2. The way the system stores the various versions of the translation information, and gives it back to the individual projects. Some projects might like the continuous stream to be squashed into one commit that says something like "Sync translations with Transifex" like it does current, some might like a Subversion dumpstream, while others like the Git project might like a fast-import stream. When we get the stream, we should be able to import it, rebase the commits as necessary, and throw away the commits that we don't like before integrating it. I'll start mocking up a solution. Are there some issues that I haven't covered yet? -- Ram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html