l10nTools Survey Results_112011/ 000755 000765 000024 00000000000 11655045435 017173 5 ustar 00jbeatty staff 000000 000000 l10nTools Survey Results_112011/._.DS_Store 000644 000765 000024 00000000122 11655034661 021065 0 ustar 00jbeatty staff 000000 000000 Mac OS X 2 R l10nTools Survey Results_112011/.DS_Store 000644 000765 000024 00000014004 11655034661 020654 0 ustar 00jbeatty staff 000000 000000 Bud1 t o o l s _ l 1 0 n t o o l s _ f i n a l r e s u l t s . h t m lIlocblob Ì ( ÿÿ T o o l s S u r v e y E x p o r t . c s vIlocblob R (ÿÿÿÿÿÿ # T o o l s S u r v e y - 1 s t r o u n d r e s u l t s . h t m lIlocblob Ø ( ÿÿ @ € @ € @ € @ E DSDB ` € @ € @ € @ l10nTools Survey Results_112011/l10ntools_finalresults.html 000644 000765 000024 00000225537 11655045432 024522 0 ustar 00jbeatty staff 000000 000000
Survey: Mozilla L10N Tools Survey
Value |
Count |
Percent % |
---|---|---|
Narro |
23 |
28.4% |
Translate Toolkit (Pootle) |
23 |
28.4% |
Mozilla Translator |
14 |
17.3% |
Koala |
1 |
1.2% |
No l10n tools, only command line or UTF-8 aware text editor |
40 |
49.4% |
Other |
17 |
21% |
Statistics |
|
---|---|
Total Responses |
81 |
Value |
Count |
Percent % |
---|---|---|
Hosted at translate.org. |
10 |
43.5% |
My own Pootle instance. |
7 |
30.4% |
Virtaal or an off-line .po editor. |
17 |
73.9% |
Statistics |
|
---|---|
Total Responses |
23 |
Count |
Response |
---|---|
1 |
It was hosted on currently down server in Kazakhstan. |
1 |
http://pootle.softcatala.org |
1 |
http://pootle.softcatala.org/ |
1 |
narro.mozest.com |
1 |
pootle.lakapps.lk (Presently not in active) |
1 |
pootle.locamotion.org |
1 |
http://pootle.librezale.org but Firefox now is being translated offline (moz2po + Virtaal) because l10n updates are not that big as before. |
Count |
Response |
---|---|
1 |
A homebrew l10n tool |
1 |
Custom scripts |
1 |
Dashboard for compare-locales output |
1 |
I've used l10nzilla and ikudart, they are in-house developments. |
1 |
IBM Translation Manager (BTW OpenTM2 is open source now) |
1 |
Localization Tools (for ja/ja-JP-mac) |
1 |
PSpad |
1 |
Poedit |
1 |
Poedit, OmegaT (before 2010) |
1 |
Qt Linguist |
1 |
Transvition (http://transvision.frenchmozilla.org ) |
1 |
Verbatim, poEdit |
1 |
compare-locales |
1 |
https://dev.mozilla.jp/l10n/lot/ |
1 |
lokalize |
1 |
omegat, verbatim pootle, trados, memoQ |
1 |
verbatim |
1 |
Just to be clear, I use Translate Toolkit but *not* Pootle (which I think refers just to the web interface). TT are command-line tools for roundtripping to/from PO. I use my own custom PO editor. |
Value |
Count |
Percent % |
---|---|---|
Yes |
25 |
32.9% |
No |
51 |
67.1% |
Statistics |
|
---|---|
Total Responses |
76 |
Count |
Response |
---|---|
1 |
From MT to command line and text editor |
1 |
From Mozilla Translator to Narro |
1 |
From Narro to plaintext. |
1 |
Generally OmegaT. But that depends on the project and the file format you use. |
1 |
I want to switch to Pootle because Narro has been sucking for last 2 months |
1 |
Koala and plain Komodo |
1 |
MT -> cmdline and text editor |
1 |
MT to Narro |
1 |
Manual to Pootle |
1 |
Mozilla Translator, pootle,narro |
1 |
Narro - UTF-8 aware text editor |
1 |
Narro -> Pootle -> text editor |
1 |
Narro to Pootle |
1 |
Pootle and Virtaal |
1 |
Pootle, Poedit |
1 |
Translate Toolkit |
1 |
Verbatim, poEdit |
1 |
We used to use only command line or UTF-8 aware text editor |
1 |
all of them(g) |
1 |
from UTF-8 aware text editor to IBM TM2 |
1 |
from moz translator to cmd line |
1 |
fron Poedit to Narro |
1 |
mozilla-translator -> l10nzilla -> own application -> command line + editor |
1 |
virtaal |
1 |
virtaal, translate toolkit |
1 |
At first I translated the bulk of work via .po files, but translations are mainteined by utf-8 text editor |
Count |
Response |
---|---|
1 |
Because MT isn't very collaborative. |
1 |
Because Narro was not sensitive to command keys and Pootle give too many trouble with conversion |
1 |
Don't remember exactly but there was some bug in the toolkit |
1 |
I didn't like Narro. Slow. |
1 |
I was looking for a web based process |
1 |
Just to test. |
1 |
Koala extension incompatibilities |
1 |
To improve the workflow. |
1 |
Unreliable on those day |
1 |
Verbatim doesn’t work offline |
1 |
Virtaal is much more flexible and allows offline editing. |
1 |
Virtaal was not Mac ready |
1 |
because availlability everywhere with internet |
1 |
efficiency |
1 |
enable translation process to less technical aware people |
1 |
moz translator output was messy back then |
1 |
need to be suitable to work online for everybody. |
1 |
not secure, not matching the job |
1 |
too complicated to compile mozilla files to po files and back to fix a few lines |
1 |
Because Narro didn't allow me to translate HTML files. Fortunately that has become possible with newer versions of Narro. |
1 |
MT kept changing sequence of keys in files, and thus made bloated changesets. Also, I didn't use MT features like glossary anyway... |
1 |
hoping to get something better than CLI + editor, the workflow was problematic, switched back to CLI |
1 |
Alex disappered and I had to change the dtds etc manually and afterwards, Narro would not sync with the Mozilla repos properly anymore |
1 |
We wanted to get more people from non-technical profiles to join our translation team. PO as intermediary format was convenient for us, since we had some tools to check translations using this format. |
1 |
Advised me not to do conversion between file formats. Narro seemed simple and easy to use. The new version of Naro not convince me. I liked the old one. Now I have all the repositories to date, I use the text editor (gedit) and helped me with tmx, glossaries and corpus. In the future, the Galician translated using Narro. Then I'll pass and I will check your work before sending it to the repository. |
Value |
Count |
Percent % |
---|---|---|
Yes |
49 |
64.5% |
No |
27 |
35.5% |
Statistics |
|
---|---|
Total Responses |
76 |
Value |
Count |
Percent % |
---|---|---|
Narro |
13 |
26% |
Translate Toolkit (Pootle) |
19 |
38% |
Mozilla Translate |
1 |
2% |
Koala |
2 |
4% |
Other |
15 |
30% |
Statistics |
|
---|---|
Total Responses |
50 |
Count |
Response |
---|---|
1 |
Any editor supporting direct contact with hg |
1 |
Any ofhter offline (not web-based) tool. |
1 |
Anyone that ease my work |
1 |
I dont trust any of the suggestions |
1 |
I'm not sure becasue I hate Pootle, if you would use transifex it would be awesome |
1 |
Launchpad.net |
1 |
No experience yet |
1 |
One that is built for L20n |
1 |
Some Transifex-like tool, for better L10n team management |
1 |
Whatever is easiest and most effective |
1 |
any .po editors like lokalize for offline translations |
1 |
don't know - native .po files would be the best option |
1 |
launchpad |
1 |
translatewiki.net |
1 |
I'm happy with Pootle but if someone did a tool that combined the capabilities of Pootle and Virtaal, I'd switch |
1 |
Yes. But it has to meet certain requirements. You have to allow you to import all the work done. Tmx files and tbx files should be allowed to use. The tool must distinguish two roles in the translated. Users who suggest a translation, and the user approves the translation. |
Value |
Count |
Percent % |
---|---|---|
Yes |
21 |
29.6% |
No |
50 |
70.4% |
Statistics |
|
---|---|
Total Responses |
71 |
Count |
Response |
---|---|
1 |
Launchpad or Transifex |
1 |
Launchpad, Transifex |
1 |
Launchpad.net |
1 |
Lokalize |
1 |
Narro |
1 |
OmegaT |
1 |
Omegat |
1 |
OpenTM2 |
1 |
Pootle, Koala |
1 |
Pootle, Virtaal |
1 |
Transifex |
1 |
Transvision |
1 |
launchpad has a nice interface for translation |
1 |
lokalize |
1 |
narro |
1 |
pootle |
1 |
spellchecker for compare-locales |
1 |
transifex |
1 |
translatewiki.net |
1 |
we were most successfull in using KDEs kbabel, now called lokalize |
1 |
I use Virtaal and Pootle for other projects, thus would choose them perhaps. The question is unclear to me though: what is 'the inventory of l10n tools for Mozilla localizers'? |
Count |
Response |
---|---|
1 |
(i18n) A tool care abuout different language and/or culture. (e.g., not asking about punctuation) |
1 |
A tool that would show the relevant interface for the translated string |
1 |
Any editor supporting direct contact with hg |
1 |
Context for strings and diff functionality for Verbatim |
1 |
I like the way Pootle is set up by LibreOffice, with plenty of error checking tools. |
1 |
It should work without the import-translate-export effort. |
1 |
Pootle format with strong terminology assistance and multilanguage control versions |
1 |
Possibly offline (please, LocalStorage), AJAX, easy commit (with LDAP perms) |
1 |
Smooth function of moz2po and po2moz, A database to insert previous translated phrases |
1 |
TM, spellchecker, dictionary, glossary are a must |
1 |
Translation memories, glossaries/terminologies, error checks, support for multiple file formats |
1 |
an online tool which is still fast and easy to figure out like a text editor |
1 |
clearly showing the open strings and suggestions. direct up/download to hg |
1 |
memory based suggestion, glossary, tool should have desktop workbench like thing, |
1 |
pootle |
1 |
terminology checker for translation. localize place indicator like Pontoon. |
1 |
translatewiki.net! |
1 |
translation memory, version control integration (hg, svn), automated fuzzy translations |
1 |
web UI, ability to download .po files and translate them offline |
1 |
Narro is close to what needs to be done, but I would like to see a place with all of the missing strings, an option to filter and see only the missing strings. See https://translations.launchpad.net/ for details. Integration with and/or use of launchpad.net would be cool. |
1 |
I'm quite happy with my own setup. Custom PO editor with good translation memory (basically, zillions of previously translated PO files in a berkeley db). What would make my life easier is for Mozilla to give me everything I need to translate as PO (incl. web properties). |
1 |
I would like to see a tool that can show the interface of the software while I translate. And a good translation memory implementation. |
1 |
translation memory, good fuzzy matches, handle placeables (tags, variables), easy import of existing localization, I found the folder concept of TM2/OpenTM2 extremely useful for dtd/properties files |
1 |
Good team management, vert fast interface (string switching, etc), shows context of the string in the source code. |
1 |
A perfect tool would not need anyone to check out any code. Just translate on the web. These tools should be supported by Mozilla rather than Narro (1 volunteer) and Pootle (few). They should not need to know anything about repositories or branches. If we could move to a DB based solution for translations then we would be in a very good shape. |
1 |
Easy way to see new untranslated strings, easy way to edit strings, easy way to see the context of the strings |
1 |
A tool that requires a translator only to translate (i.e. no mercurial, no lines of code, no repo this and that), a tool that incorporates a live translation memory and crucially, something that includes other open source projects on the same platform (i.e. Mozilla, LibreOffice, VLC, WordPress etc etc) all on the same platform so existing translation can be used most effectively, |
1 |
The tool would have to directly import the new strings to translate (like Verbatim). The tool should allow use of translation memories and glossaries (TMX and TBX). Each team should be able to import your translation memories. The tool would have to use spell checkers for each language. The tool should suggest translations from the already translated strings (like Launchpad or Narro) The tool should allow the state to mark the chains (dubious, unproven, approved). The tool has to distinguish user roles. Users who translated (translations suggest). Users who approve the translations (review and approve the translations) [as Narro] The tool should allow suggestions for translations of other languages ​​(as Narro) The tool should export your work to the repository (without using hg by the coordinator) |
1 |
Automatically flag strings that were changed in english. Automatically manage check-ins to branches. |
1 |
easy to import/export to hg, automated commit after translation is done; email notification when new proposals are commited. |
1 |
support variable replacement or template system with variable like django template (to support ja/ja-JP-mac), need to be able to edit any content like editor when needed (like cloud9 ace?) |
1 |
UI displays all strings in all files instead of working on a single file, Translate from existing glossary, import other formats like po and properties, check for errors like shortcut key mismatch |
1 |
An automanageable tool, with autosync, an effective translation memory, like Transifex or Launchpad |
1 |
I see the dashboard as the potential perfect l10n tool. The features I'd like to see added are: HG support (pull & commit + push), removing obsolete strings and files, adding missing strings and files, listing unchanged strings and the ability to translate using integrated web-based text editor, e.g. ace.ajax.org. |
1 |
a tool that can be able to help in translate with consistency and maitaining stardardised for whole software |
1 |
Built for L20n, coping with dtd/properties, good search across all original/localized strings and string IDs, able to detect changes of original strings when string IDs didn't change, keeping all original file strucutre intact and only switching out the strings for localized versions, knowing about and displaying localization notes, quick table-style display and editing of missing/changed strings, ability to carry over localized strings if files or groups of strings only have been moved around, ability to fill in strings semi-automatically when a localization of the same original string already appears elsewhere |
1 |
We have recently switch between from only using command line and a PO editor to a local Pootle solution. Pootle solution is good for translators but It has some inconvenients. Pootle could be the perfect tool if these uses were fixed: * It lacks an easy task to copy translations from one file to an another. Some files are the same in Firefox and Seamonkey project. In order to be coherent between project translations is good to copy tranlations from one project to the other. * The process to move tranlsations from Pootle to Mercurial is quite complex and there is a risk of loosing data. Before commiting changes I run a shell * When generation PO files, Translate Toolkit creates msgid "" and msgstr "". For example msgid="contribute.end" in browser/chrome/browser/aboutDialog.dtd.po * When generation PO files it has problems with some UTF-8 characters (for example with middle dot U+00B7) |
1 |
1) easy to make changes (web interface) 2) supports multiple people working on same strings at the same time 3) reviewing functionality for suggestions from new people 4) easy to subscribe to the list of changes both for new strings added and for strings translated for easy access to proof-reading 5) understands new release calendar (can tell you how much time you have left for changes or when to expect next batch of changes) |
1 |
Multiplatform (mac, win, linux) and usable offline, translation suggestions based on a local translation memory, possibly integration with vcs system (e.g. hg) at least at commit level |
1 |
Mozilla Translator has pretty much everything needed. Adding the possibility to manage repos from whithin the program would be great. |
1 |
It would be good to update translations from a previous .xpi langpack, knowing what strings have changed or are new, translate them and with a button clicking rebuild .xpi langpack again |
1 |
The dream tool would be one that augments my localization flow such that the tideous tasks become automatic. Like inserting new strings into files __in their proper location__ (or marking them for deletion), is able to check for access key dupes in the UI, a more RRP-aware signoff process, output from CompareLocale to be ordered by key sequence (also list line numbering) |
1 |
No need to worry about repositories' setup, no need to get the whole codebase for getting the actual l10n files, ability to co-work online and also offline, easy for newcomers but with the ability to set fine-grained restrictions/permissions. |
1 |
It should be something easy like KBabel was for po files. Translate and commit from the same place. So translator can translate. At the moment most of the time is going under diffing and copying. It's a bit annoying and time consuming. |
1 |
Online/Offline editing, live quality checks, built-in file browser, terminology management, better suggestions |
1 |
Easy import/export from/to many different formats. Ability to keep rejected translations and statistics on contributors. Automatic notification. Ability to work offline. |
1 |
three simultaneous views: localized text before and after translation (that is: old and new translation) and original (en) text. More important: a way to see where the strings belong in the actual application. |
1 |
web based: Pootle with faster and easier navigation between strings (AFAIK, it's being worked on). Desktop: it's harder to summarize. I've used a few different tools for different projects, and I'd surely find at least something to improve in each one. Virtaal lacks (I guess) multiple file support and easy navigation between contexts. Many other tools lack TM or easy navigation between strings. I haven't tried Koala, to be fair - never heard of it. But screenshots look really promising! |
1 |
From my experience, Pootle is fine. But we miss a better tracking of user contributions and the option email notifications. Also a live translation memory from your own translations, which could act as another suggestion source. The most important con (from an admin -not translator- POV) is that the process of importing and exporting the strings back to Mercurial is a bit cumbersome. |
1 |
Easy to use; Abstracts away from formats to focus on text; Includes TM matching; Offers terminology suggestions; Allows work to be grouped and prioritised; |
1 |
I would go for a more webbased system like verbatim, no more downloading, edit everywhere, easier adding multiple editors. |
1 |
Well, I'm familiarized with Launchpad, Pootle, and Transifex. The way to do translations it's very simple, quick and kindly visual (graphically) |
1 |
Offline, no complex installation, quick, keyboard-based, with auto-translation, translation suggestions, translation memory, glossary, quality assurance automated checks... |
Value |
Count |
Percent % |
---|---|---|
Yes |
65 |
83.3% |
No |
13 |
16.7% |
Statistics |
|
---|---|
Total Responses |
78 |
Value |
Count |
Percent % |
---|---|---|
Firefox mobile |
38 |
56.7% |
Thunderbird |
48 |
71.6% |
Calendar |
38 |
56.7% |
SeaMonkey |
26 |
38.8% |
Fennec |
29 |
43.3% |
MDN |
12 |
17.9% |
Mozilla websites and engagement projects |
40 |
59.7% |
SUMO |
22 |
32.8% |
AMO |
19 |
28.4% |
Individual add-ons |
9 |
13.4% |
Songbird |
2 |
3% |
Other |
5 |
7.5% |
Statistics |
|
---|---|
Total Responses |
67 |
Count |
Response |
---|---|
1 |
Flock |
1 |
KompoZer, Bugzilla |
1 |
bluegriffon |
1 |
hacks.mozilla.org, Songbird etc. |
1 |
the add-ons themselves. |
Value |
Count |
Percent % |
---|---|---|
True |
63 |
81.8% |
False |
14 |
18.2% |
Statistics |
|
---|---|
Total Responses |
77 |
Value |
Count |
Percent % |
---|---|---|
True |
27 |
36% |
False |
48 |
64% |
Statistics |
|
---|---|
Total Responses |
75 |
Count |
Response |
---|---|
1 |
695997 |
1 |
Dashboard. Updates too slowly. Should be a label to show time of last build. |
1 |
I'm the current coder of MozillaTranslator, so I do my best to fix bugs that annoy me. .:-) |
1 |
Improving performance of Narro would be good but |
1 |
Lokalize |
1 |
More than bugs, I see features to be added, as I commented before |
1 |
Narro |
1 |
Narro performance. It is very slow. I do not like the new interface. |
1 |
Not bug, but need to rewrite with python to integrate with existing mozilla build system |
1 |
RTL Input support in narro |
1 |
http://bugs.locamotion.org/show_bug.cgi?id=329 http://bugs.locamotion.org/show_bug.cgi?id=1718 |
1 |
it's more omplex than that. but then https://bugzilla.mozilla.org/show_bug.cgi?id=412597 |
1 |
narro |
1 |
not sure, I use a text editor because the more specialized tools are slow and hard to use |
1 |
still several things to fix with pootle and lokalise |
1 |
too many |
1 |
usability. |
Value |
Count |
Percent % |
---|---|---|
True |
36 |
47.4% |
False |
40 |
52.6% |
Statistics |
|
---|---|
Total Responses |
76 |
Count |
Response |
---|---|
1 |
Because it needs action from localizers more often |
1 |
Because it never happens I have 500 strings to translate. |
1 |
Because there is a chance to catch up by the next release even if you miss the current one |
1 |
Continuous work = less work |
1 |
Difficult due to proper channeling of work |
1 |
Every six week is too fast |
1 |
Fixed schedule, regular and not that big updates. |
1 |
Fixed string freeze times |
1 |
Fixed time for localisation with string free in place. |
1 |
I don't localize Firefox. |
1 |
I'm not sure, but i think that rapid releases dinamics groups of localizers |
1 |
It is always easy to do small task rather than a bunch of heavy workload. |
1 |
Less focus on quality. |
1 |
Less work at a time. |
1 |
More effort from l10n teams, specially small ones. |
1 |
New teams can join the process quickly and see the fruit of their effort if they keep up |
1 |
Not need to create new repo/branching anymore |
1 |
Only true for already completed languages, for new languages it is rather frustrating! |
1 |
Predictability |
1 |
Small amount of changes should be done once in every 6 weeks, it is easy to move with |
1 |
We don't have enough time to translate |
1 |
Well known dates, easier to manage my own time |
1 |
With RR, I *have* to find some time in every 6-week period to contribute |
1 |
a lack of time. |
1 |
each time the changes are smaller. no big bang. |
1 |
less workload |
1 |
more time for testing |
1 |
more time to localize strings after a string freeze, fewer strings to localize between releases |
1 |
simply the pace of things. might also be question of getting used to. |
1 |
there is nice 6 weeka window with no string changes. |
1 |
In tiny teams, it's easy to miss a release (holiday, sickness etc) which means there is a release gap for that locale because Mozilla only accepts 100% translations for releases. At the current speed (and to encourage new locales), the threshold should be lowered to ~50% |
1 |
even when rapid releases have less to translate, there's a fixed "price" that accumulates to a lot of work for small changes (because l10n tools suck) |
1 |
Knowing that strings are frozen for 6-12 weeks on a schedule makes it very easy to plan ahead of time. |
1 |
Changes go to live environment faster, and no option to collect long list of untranslated items. mobilizes to work. |
1 |
Merging issues, syncing between Firefox, Thunderbird and other projects ("aurora" should be about Firefox only, let other apps have their own aurora-like branches) |
1 |
The effort for each release is less - making it easier. The responsiveness to accepting new languages is as slow as it ever was, or worse - making it potentially harder |
1 |
Clear schedule, real string freezes, short number of strings between releases, enough time to test before final release |
1 |
Today we have a fixed number of branches and they are always the same. Before we need to change to a new branch on every release. |
1 |
It's both easier and more difficult. On one hand, string differences are smaller. On the other, schedule is tighter. I guess whether or not it's harder, depends on each team in question. For me, not much has changed. Although I somehow hope we'll quit this rapid release schedule. We don't have to play this version number game just to catch to other browser versions IMO. |
1 |
Makes it more complicated to update translations of older versions, because there are so many releases in a short time |
1 |
Localizers need to update and sing-off many times than before. OTOH fixed schedule is really good. |
1 |
I need to work on every couple of weeks. Pull/import/translate/export/commit/push cycle takes a lot of time, and "translate" is sometimes only a few minutes. I preferred to work with bigger chunks of translatable text. |
1 |
Rapid release is pehraps good for the user or the full time developpers, but benevolent contributor don't always have the time or the nerve to follow the rapid release. |
1 |
Every 6 weeks you see how many new strings have to be translated; and you know they have to be done in 6 weeks. It's much easyer for planning. |
1 |
That's a big topic. Basically: I struggle to get to product localisation every 6 weeks. In between there is AMO and other things that need attention. Mozilla is just one of the places where I contribute to localisation, and it is taking time for the other projects. Apart from that, I like to do things that are not localisation. |
1 |
The rapid-release schedule makes our work difficult to maintain in a short-time basis, because volunteers could not have enough time to use for localizations. |
1 |
I do not know what to say. I have only problems with transplants in the repositories. I do it manually, I can not do otherwise. |
1 |
predictability. The developers no longer come in late and changes stuff after it is translated. Work is split upinto smaller parts |
1 |
I now spend a predictable 3-4 hours every 6 weeks vs. hundreds of hours keeping up with a moving target over a longer cycle. Love it! |
1 |
Translating greater number of small batch updates is, IMHO, easier than translating few big batches of new strings |
1 |
There's a faster turnaround - and fewer strings to handle. On the other hand, this requires a more intense and sustained commitment from localizers and their local community because of the limited turnaround time. |
Value |
Count |
Percent % |
---|---|---|
True |
17 |
58.6% |
False |
12 |
41.4% |
Statistics |
|
---|---|
Total Responses |
29 |
Count |
Response |
---|---|
1 |
Because you have to find free time frequently |
1 |
I think this should have been one question, not two. |
1 |
It makes short the period of time to reviewing. |
1 |
It would be easier for localizers if they had to less often localize new strings. |
1 |
It's complicated, too many branches, some of them updated automatically other not. |
1 |
L10n bugs need to be fixed in three "branches" |
1 |
More repositories to consider |
1 |
The past numbering scheme had useful version info |
1 |
The schedules are very tight. |
1 |
it's a bedlam, what else can I say |
1 |
less time to keep the localization updated |
1 |
less time to localize, and having to do it more often. |
1 |
Even though, now releases have less strings to translate, teams need to be better organised, and there is a higher need of people backup in case anyone is not available for a while. This raises the need to have easier-to-use (ideally web-based) tools. |
1 |
The amount of work to do between each release is smaller than before but we have to find more disponibility. We have to find time every 6 weeks to update the translation. I would prefer a longer cycle (2-3 months ?). |
1 |
Some time it hampers our work schedules as I work for several other open source projects. Also it effects my other priorty tasks. |
Value |
Count |
Percent % |
---|---|---|
True |
44 |
57.9% |
False |
32 |
42.1% |
Statistics |
|
---|---|
Total Responses |
76 |
Value |
Count |
Percent % |
---|---|---|
True |
44 |
58.7% |
False |
31 |
41.3% |
Statistics |
|
---|---|
Total Responses |
75 |
Value |
Count |
Percent % |
---|---|---|
Never |
37 |
48.7% |
Occasionally |
29 |
38.2% |
Frequently |
10 |
13.2% |
Statistics |
|
---|---|
Total Responses |
76 |
Value |
Count |
Percent % |
---|---|---|
Never |
35 |
46.1% |
Occasionally |
29 |
38.2% |
Frequently |
12 |
15.8% |
Statistics |
|
---|---|
Total Responses |
76 |
Value |
Count |
Percent % |
---|---|---|
I work on my own |
24 |
31.2% |
I work with a group |
25 |
32.5% |
Both |
28 |
36.4% |
Statistics |
|
---|---|
Total Responses |
77 |
Value |
Count |
Percent % |
---|---|---|
1 - 2 |
36 |
61% |
3 - 5 |
17 |
28.8% |
6 or more |
6 |
10.2% |
Statistics |
|
---|---|
Total Responses |
59 |
Sum |
123.0 |
Average |
2.1 |
StdDev |
1.59 |
Max |
6.0 |
Value |
Count |
Percent % |
---|---|---|
On-line |
21 |
32.3% |
Off-line |
27 |
41.5% |
Both |
17 |
26.2% |
Statistics |
|
---|---|
Total Responses |
65 |
Value |
Count |
Percent % |
---|---|---|
Poor |
33 |
45.2% |
Adequate |
39 |
53.4% |
Excellent |
1 |
1.4% |
Statistics |
|
---|---|
Total Responses |
73 |