Thread (14 messages) flat view 14 messages, 5 authors, 2016-06-15

Re: Using Transifex in git.git

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:51:28

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help