Re: Problems commiting damned-lies package



I think WebLate would be a good pick. It has a glossary function too,
which teams will find handy to help with terminology consistency. And
you can download the files to translate too, in a long list of formats
of your choice. And it has some QA checks too, like punctuation, printf
placeholders etc.

I only tried to translate a project once on Zanata and found the
experience frustrating enough that I decided to go off and translate
something else.

And while I have become pretty skilled in using Git for programming work
and I love how powerful it is, I don't want to use Git directly while
translating.

IMO the optimum workflow would be to pull weblate translations with a
scheduled GitLab CI job and let the CI commit them into a branch when
they're green. The master branch should be protected and nobody should
be allowed to push there directly. Even skilled and experienced project
maintainers will make mistakes, because nobody is perfect.



Sgrìobh Carlos Soriano na leanas 22/06/2020 aig 13:47:
Hey Daniel,

First of all, I want to say that I see your POV, and you cannot change
the whole thing by yourself and I'm glad you are pushing to address
these translators' pain points in your time. I do agree on the technical
side with Emannuelle, but I also understand it's not something that will
happen unless some developer with the right skillset invests the time to
do it, and that might be harder to find on the gnome-i18n group.

I believe the issue is limited to certain groups, since you have access
already for the GNOME group right? If so, it's a bit tricky, as those
projects are not necessarily fully tied to GNOME. We don't support them
in the same way we support the GNOME group, that is by design and as a
result of having a more open infrastructure than we had before - now
everyone can create their own personal project in GNOME's GitLab, even
if they don't have commit rights to GNOME projects.

Now, I don't see why we wouldn't make it easy for translators of GNOME
to provide translations in other projects in our infra if desired, as
long as we make the difference between GNOME projects and the rest clear
in DL. We also have to acknowledge that certain projects might want to
handle their permissions and workflow differently - they might block the
master branch to anyone but maintainers. It's a reality that MR + CI is
becoming the de facto approach, and the longer we take to transition to
something else, the more painful is going to be for gnome-i18n.

For a possible short term solution, could you file a GitLab ticket
at https://gitlab.gnome.org/Infrastructure/GitLab detailing which groups
or projects you would like to have access to, and the requirements and
use cases that the gnome-i18n has for having commit right access? That
way, it is not blocked on me or our own private communication.

As a long term solution, did gnome-i18n investigate if there are other
tools available (Zanata, WebLate, etc.) that would fit what we need
here? I understand DL was created with certain features and workflows
that fit well GNOME, but I have the feeling times are changing faster
than we can adapt and we cannot find the developer resources to do so.
Adopting one of those external tools might open new possibilities
too, and bring a new type of contributors.

Let me know if you have any other comments.

On Mon, 22 Jun 2020 at 13:29, Daniel Mustieles García
<daniel mustieles gmail com <mailto:daniel mustieles gmail com>> wrote:

    Again this is David against Goliat, and I'm tired of fighting...

    I have no skills to improve DL, I only developed a script and made
    it available to everyone who wants use/read/whatever with it. If if
    can be a start point to improve DL great! but I'm not going to keep
    fighting against something that I cannot change.

    I don't know which features Gitlab offers, sorry if I still think
    like in 2009. Maybe someone with better knowledge than me could show
    us the proper way or even help with a tool or a patch for DL. I made
    a bash script  because I don't know Python. I'm a translator, not a
    developer, sorry.

    I'm leaving here the discussion/thread, but thanks for your comments
    and your point of view.

    Regards

    El lun., 22 jun. 2020 a las 13:13, Emmanuele Bassi
    (<ebassi gmail com <mailto:ebassi gmail com>>) escribió:

        On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García
        <daniel mustieles gmail com <mailto:daniel mustieles gmail com>>
        wrote:

            Hi Emmanuele,

            Just a quick question: which is the difference between
            commiting directly into Git and commiting through DL?


        DL can, at least, centralise the place where tests are executed
        to ensure that things don't utterly break. Of course, it's not
        really a solution: now that we use GitLab, we already have a
        centralised place to run builds and tests.

        The fact that DL pushes to the main development branch *also*
        irks me to no end; at least DL acts as a filter, and ensures
        that *some* validation is actually performed.
         

            PO file checks are the same (or should be), so commiting
            directly is not more dangerous than using DL. the same
            checks DL makes into a PO file are done in my script, for
            example. If a PO file breaks your module's building it
            doesn't matter if I committed it directly into git or usind DL.


        Your script is your own script. Unless everybody uses your
        script—in which case, it should be moved to a remote environment
        so that people don't have to have Git access—then it's pointless.

        But my point is that I don't want translators to have "scripts".
        I don't want translators to do anything more than translating.
        We have infrastructure to verify that things pushed to the
        repository do not break the main development branch of a
        project: it's called the continuous integration pipeline, and we
        have a process for it to run on topic branches. We even have API
        in GitLab to:

         - automatically create a merge request
         - set the target branch
         - automatically merge code once the CI pipeline passes
         - automatically remove the source branch when merged

        when pushing to the remote repository:
        https://docs.gitlab.com/ee/user/project/push_options.html

        I do hope your script uses it. I'd hope for DL to do the same.
         

            Also, note that not all translators will have commit rights:
            only a reduced group of them. Breaking things in git is
            possible for both translators and developers: that's one of
            the reasons we use Git, to be able to revert commits and
            even revoke commit access to a person who breaks things
            several times.


        I don't want to manually revert stuff that's broken and got
        pushed to the main development branch. I don't want broken stuff
        to land *in the first place*.

        Git having easy revert operations is good for things that are
        *discovered* to be broken later on; that doesn't mean people
        should push broken localisations of the application
        documentation, with broken tags that do not close properly, and
        get only discovered when trying to release something. That's
        sacrificing maintenance time—*my* time—because you want to save
        your time. Your time isn't any more precious than mine.

        Additionally, we have whole run times that get built every day;
        if a translation breaks a library, or an application, the whole
        pipeline gets stalled until the problem is solved. The amount of
        lost person time is staggering.

            This is not a question of being 20 years o 20 days in the
            project: this is a question of helping us with our work,
            because that work is as valid as yours, and we all are
            responsible with it. pre-commit hooks can be implemented
            (they are already, but we could study if are enough or not)
            to avoid breaking things, but its really discouraging to
            follow DL's workflow to commit a 1-modified string in a PO
            file. Multiply it by 20...


        If people spent time improving Damned Lies instead of working
        around it with their own scripts, we would probably have a
        better tool already.

        Or, maybe, a better tool already exists, and we should move to it.

        In any case, my point is that even people that can commit to Git
        *should not* push to the main development branch. *Ever*. The
        mere fact that you reference "commit hooks" makes me think
        you're basically thinking that we're using Git by itself, like
        this is still 2009. We don't. We switched to GitLab because it
        offers us a lot more tools that "hooks". We have CI pipelines
        that run on branches; merge requests; an entire API to construct
        tools on top of our infrastructure.

            We don't want special snowflakes, we just want to be able to
            do our work in the best way.


        Your "best way" has a high chance to make me waste my time, when
        we have perfectly functional tools to avoid that.

        I'm grateful for the work done by localisation teams; lowering
        the bar of contribution makes it better for everyone, but that
        should never come at the cost of the stability of the platform.

        The solution to making GNOME software better is not to make
        everyone expert developers, but to make sure our infrastructure
        is automated and safe to contribute to—and "safe" doesn't mean
        "I can revert broken stuff after the fact". That principle has
        been one of the driving force of a lot of the changes in our
        infrastructure over the years.

        Ciao,
         Emmanuele.

            Regards

            El lun., 22 jun. 2020 a las 12:30, Emmanuele Bassi
            (<ebassi gmail com <mailto:ebassi gmail com>>) escribió:

                Hi;

                to be brutally honest, as a maintainer I don't want any
                translator to commit directly to Git—unless it's done to
                a separate branch and/or through merge requests.

                Translators do not build the projects they translate,
                and they don't (or cannot) know when they break things.
                The only way maintainers know that a broken translation
                happened is that suddenly the CI mails us, and then we
                have to hunt down what happened behind out backs. This
                is even worse when you realise something has broken a
                long time ago because the release process is now impossible.

                I'd rather have an automated, web UI tool that pushed
                changes to a branch and opened a merge request that ran
                the CI pipeline (and maybe the dist process), than
                allowing translators to commit to Git directly. I don't
                really care if some translator is an old hand that was
                around when GNOME used CVS and scripted their way to
                push to dozens of repositories at once; we started using
                a lot of tooling to ensure things don't break, and even
                developers have started pushing things to development
                branches instead of committing directly to master. I
                don't see why translators have to be the special
                snowflakes of the whole GNOME project, and break stuff
                for everyone else just because of their 20 years old
                workflow.

                Ciao,
                 Emmanuele.

                On Mon, 22 Jun 2020 at 11:03, Daniel Mustieles García
                via gnome-i18n <gnome-i18n gnome org
                <mailto:gnome-i18n gnome org>> wrote:

                    Some time ago I talked about this with +Carlos
                    Soriano <mailto:csoriano gnome org> . I asked him
                    about the possibility of creating a user's group in
                    Gitlab, formed by some team coordinators, which will
                    have commit rights to be able to commit a bunch of
                    translations due to the heavy clickwork must be done
                    in DL. Still waiting...

                    Me (and some other team coordinators) got Git access
                    before migration to Gitlab, and it was not a
                    problem. Having such rights will help us a lot to be
                    more agile maintaining and commiting translations.
                    Yes, I currently have those rights and can use an
                    automated script [1] to ease my life, but I don't
                    have commit rights in some new modules
                    (app-icon-preview, shortwave...). I'd like to
                    formerly request this feature/rigths. If we found
                    any problem with a wrong commit or something like
                    that is quick and easy to revert that commit; if a
                    user with rights uses them for other things that
                    translations is quick and easy to revoke those
                    privileges. Advantages for us to maintain and keep
                    translations up-to-date are huge.

                    Please consider this request and let's work together
                    to make it possible in the best way.

                    Best regards.

                    [1]https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh

                    El dom., 21 jun. 2020 a las 20:43, Matej Urban via
                    gnome-i18n (<gnome-i18n gnome org
                    <mailto:gnome-i18n gnome org>>) escribió:

                        Hello,
                        some time ago I complained about inability to
                        commit damned-lies package due to wrong access
                        rights. Ok, I can live with that, but lately I
                        get this error on many, many packages,
                        especially new ones, like:

                        app-icon-preview, authenticator, fractal,
                        fragments, gnome-keysign, obfuscate, shortwave
                        ... list goes on

                        Is there any special reason why not even
                        coordinators are able to do that the usual way?
                        Yes, I know, there is another way to do it, but
                        it is cumbersome and takes a lot, lot, lot time
                        to do it and what is more important, each
                        project has some specifics. For this reasons I
                        do not push these ...

                        Please advise or better, please bend at least
                        for coordinators these rules.

                        Thank you,
                        Matej


                        _______________________________________________
                        gnome-i18n mailing list
                        gnome-i18n gnome org <mailto:gnome-i18n gnome org>
                        https://mail.gnome.org/mailman/listinfo/gnome-i18n

                    _______________________________________________
                    gnome-i18n mailing list
                    gnome-i18n gnome org <mailto:gnome-i18n gnome org>
                    https://mail.gnome.org/mailman/listinfo/gnome-i18n



                -- 
                https://www.bassi.io
                [@] ebassi [@gmail.com <http://gmail.com>]



        -- 
        https://www.bassi.io
        [@] ebassi [@gmail.com <http://gmail.com>]


_______________________________________________
gnome-i18n mailing list
gnome-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]