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.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation
--
To unsubscribe e-mail to: l10n+unsubscr...@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
