On Wed, May 29, 2013 at 9:48 PM, Andras Timar <[hidden email]> wrote:
> On Wed, May 29, 2013 at 5:46 PM, Rimas Kudelis <[hidden email]> wrote:
>> IMO, listing all three when only one is the actual marker would result
>> in more confusion than benefit. For example, the & character seems quite
>> common in English to me. Falsely marking it as an accelerator marker
>> would result in bad indexes, I guess...
> OK, I have another revolutionary idea. Let's forget about &, there are
> only a few. What about changing the ~ to _ in VCL? Of course po files
> will be changed accordingly.
If it allows us to get from +- 2 markers to +- 1 marker, I think it
can be good in the long term. You mention a compendium elsewhere in
the thread. I wouldn't use that (since you can't control which strings
are reused where). Using msgfilter from the gettext package should
edit things file by file, which is hopefully (!) safe.
I think we should see this as a major change and plan well for it.
Pootle cares about more than just the accelerator marker. It also has
knowledge of the variable styles. I guess this would require the
introduction of a custom libreoffice style with the '_' accelerator
marker, but the variables as before. Ideally we should also review all
the variable styles and see if they are really still used (there are
lots of them). So if we decide to go this way, let us make sure the
tools are ready before that change so that we don't have unnecessary
mismatches or false alarms for variables/accelerators.
It will take some time to get a new version of Virtaal out, I think.
I'm not sure which other tools might be affected by such changes.
By the way, is '&' just used for the windows installer?
Hi Martin, all,
On 29/05/2013 23:00, Martin Srebotnjak wrote:
> Hi, all,
> I see this as a recurring problem.
> Developers do some change in several files in many strings, because that
> seems appropriate and cleaner, and they do it:
> a) without thinking what that change will mean for translators
> b) knowing it will cause a lot of manual work for translators, but they
> think that is collateral damage.
I don't think so, they see the change needed, so they do it because it's
needed. What is completely lacking here is communication and
organization in the workflow with us.
> I know this from OOo and it happens with LO as well.
> Adding "_" as an accelerator should have made programmers think about it:
> changing same strings with accelerators from tilde to underscore made a lot
> of manual work for translators of more than 100 languages - one changed UI
> string in this manner meant more than 100 people had to manually change
> that string ... And there were hundred(s) of such strings, more to come.
Yes, but if it's a need for the product, it has to be done, it's the
same for the developers who has all the .ui to write again. And see,
Andras has tried to minimize our work at best. So we can't say that
developers don't care about us.
> But that is all history now.
> Since underscore is more likely to appear in "normal" strings than tilde
> (or at least I would suppose so) - why not make it the other way than what
> Andras suggests - so that with a script in all specially marked po files
> tildes would be changed to underscore? Or introduce some kind of
> meta-accelerator (%ACC)?
I don't know if it's possible, but I would like to be able to set the
same accelerators that in the previous dialogs.
> There is one thing I miss from the OOo-Munich days - I am not sure how that
> was called - but every time a new feature or bigger change was introduced,
> there was a report/plan what it will mean, what needs to be done, how the
> UI will look like etc. I think that the developers should adopt that same
> or similar system and get some approval by a bigger developers/translators
> community, and there should be a section in such a document weighing in the
> work/changes by this new feature/development for the localizers. Hopefully
> then more than 100 localizers would have a few more hours to test their
> translations and not just to copy/paste/change a character.
Part of the changes could be found on the feature page here:
https://wiki.documentfoundation.org/ReleaseNotes/4.1 but yes, I would like to see more communication on the work we will have
and also a complete list of the changes/new strings and I don't want to
have to rely on git to find what the string means (in the middle of the
strange developers language).
For OOo, we did have specs that was very helpful for us, not only on
localization but also on documentation. But that doesn't exists in
LibreOffice however we need more visibility on the work we have to do
and it's difficulty (a new function in Calc takes me half a day to
May be this is something to put on the list to be discussed at the next
> And I know I will slapped for my thoughts again, as usually, so I humbly
> rest my case.
Ho no, we know you :) More seriously it's important that everybody
working here gives his point of view and his feelings, we need to find
solutions to be better next time. I sent a mail some times ago to ask
for feedback on what you (the l10n group) want to see discussed at the
LibOCon and if we want to try to set up an irc chat for those who can't
attend. I'll resend my mail soon, but put your feedback on my list already.