Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


Hi all,

Some news about the workflow. I attended the ESC meeting and the minutes
of that part are below, discussion is still open. Coming back from
Fosdem where Cloph, Alex, Florian and me met with Dwayne. It has been
decided to put the new version on test by the end of the month, that
should solve the performance issue and some other bugs. If you wish to
participate to the test period, please rise your hand :)

* Translations problems (Sophie)
    + big chunk of translations for 4.4, to change our workflow to work on
      master instead of branches; so we can get visibility into that sooner
      and smooth the workload out.
        + 3x points on the dev. side.
        1. ensure respect the en_US strings
             follow rules for sentance capitalization
             [
https://developer.gnome.org/hig-book/3.2/design-text-labels.html.en
               we re-use the GNOME HIG here ]
             saves thrash that hurts translators.
        2. don't commit changes eg. appending '...' to menu items
           please discuss this with l10n before big-impact changes.
            + UX type thing (Kendy)
                + proposal from translators; make en_US a separate lang.
                  touch the strings in the repo - as minimally as possible;
                + don't think this will work long-term; will need to improve
                  what we have in the repo.
                + proposal is a tech. sol'n for a social problem.
                + for large-scale changes UX should talk to l10n first.
                + would be useful to have a l10n person in the UX call.
            + hopefully as/when everyone works on master, it is easy to see
              and have a tighter feedback cycle between the two teams.
            + UX & QA calls at the same time (Sophie)
AI:             + sort out the calls (Kendy / Sophie)
        3. changes that affect all languages can be scripted
            + eg. _ in dialogs; could have been scripted; would like that
              tested on several languages
                + scripts should be applied out of pootle.
            Is there a way to do that ? (Caolan)
                + hackers see a git repo - which is a copy of what is
                  in pootle
                + it'd be good to allow translators to see where the
                  translations actually are.
                + either git is canonical, or have some well defined
                  tooling to switch between.
            Is this a common problem now (Michael)
                + not particularly, but perhaps wrt. a gettext move (Caolan)
                + changing things wrt. a GNOME-HIG
                    + putting a ':' at the end of labels.
                    + discouraging.
        + what is the process of database (Michael)
            + DB -> po files -> script -> then files with changes
checked -> git. (Cloph)
            + if we drop the format in the repo, could sync to & fro (Cloph)
                 + with built-in pootle functionality; so pootle would allow
                   commits directly to git
                 + would create 100's of commits whenever pootle changes
stuff
                 + if translators use off-line .po files, would
overwrite changes
                   in the repo.
            + already the po files are multi-GB in size; the change-sets
would be
              huge for replacements.
                 + can't we do that for master (Markus)
                     + and at feature-freeze throw away the old history
                 + wonder if git is useful there (Thorsten)
                     + is it an attempt to fix a social problem with a
tech. problem.
        + scripting / changes in parallel are a problem (Stephan)
            + if that happens, we get conflicts -> always.
            + hold off for 2x weeks - while doing a change.
            + if we have a git repo where things are sneaked in
underneath translators.
            + any big changes with a script, but can't be done with a
technical protocol.
        + pootle on a branch, and a master repo ? (Bjoern)
            + wouldn't need a separate repo, but would need permissions
              from web interface (Cloph)
                 + git repo easier to manage,
        + export pootle to a branch & merge them to master (Andras)
            + would need 2x repos, and directory layout not the same (Cloph)
                 + can make it the same (Andras)

Cheers
Sophie
-- 
Sophie Gautier sophie.gautier@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation

-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.