Re: [libreoffice-l10n] Re: [libreoffice-l10n] Re: [libreoffice-l10n] Re: [libreoffice-l10n] n’t → n't

2014-11-30 Thread Rimas Kudelis
2014.11.30 07:38, Yury Tarasievich rašė:
> On 11/30/2014 05:13 AM, Adolfo Jayme Barrientos wrote:
> ...
>> In case you guys didn’t know, Apple [1], Microsoft [2] and GNOME [3]
>> are all recommending the use of typographical apostrophes and
>> quotation marks, among other characters that have been historically
> ...
>
> Said recommendations, while formaly correct, are subverted by the fact
> that there are no commonly accessible methods to keyboard-input all
> those "fancy" glyphs.
>
> In OpenOffice (and in Word?) you may have add-ons, auto-correcting
> some of those cases. Otherwise than that you'd have to install
> smarty-pants (often, pain-in-the-..., too) keyboard input correctors
> or resort to mouse-clicking in the glyph tables.

Just a reminder: in Pootle, it's possible to specify harder-to-input
characters for each language, which are then made available below the
text input field when localizing. While it's less convenient than
inputting them with the keyboard, it's still better than having a
separate character map application launched just to copy these few
characters. Furthermore, I think Pootle even shows such Unicode
characters in the source string as placeables, making them clickable.

And if you use Windows and want to make inputting these characters even
more convenient, you can always customize your keyboard layout adding
missing typographical  symbols to the AltGr (or any other) layer. Here's
a free tool to do that:
http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx.

>> I am actually planning to update the rest of strings in LibreOffice to
>> use the correct characters, but I guessed I had already annoyed the
>> other translators too much for this version, so that would be in 4.5.
>
> So you will still annoy the translators, only more.
>
> Program UI isn't a typography showcase. Why not leave the pragmatic
> simplification which serves it purpose? Does it break anything? 

I agree this will be annoying, because at the very least, the localizers
will have to re-approve a lot of their old translations when these
changes land. At least in the case of "don't" though, maybe this change
could be automated, if we ask Andras or Christian nicely? :)

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Re: [libreoffice-l10n] Re: [libreoffice-l10n] Re: [libreoffice-l10n] Re: [libreoffice-l10n] Re: [libreoffice-l10n] n’t → n't

2014-11-30 Thread Rimas Kudelis
Hi,

2014.11.30 16:23, Christian Lohmaier wrote:
>>> I agree this will be annoying, because at the very least, the localizers
>>> will have to re-approve a lot of their old translations when these
>>> changes land. At least in the case of "don't" though, maybe this change
>>> could be automated, if we ask Andras or Christian nicely? :)
> Well, the only thing that can be done is to apply the old strings
> despite the typographic changes, i.e. do a run that maps all
> typographic quotes back to simple variants and then try to find an old
> translation for that string and apply it.
> In other words: Change the English string to typographic quotes, and
> take the translations from the non-typographic variant.
>
> So translators wouldn't need to retranslate, but also wouldn't see
> what strings did change.

If this can be done, I'm sure it would make most localizers happier.
Especially in cases like "don't", where the translation most likely
doesn't even contain the glyph that has changed. As for quotes, these
most likely exist in localized content as well, but I'd say it has been
localizer's responsibility to use typographically correct ones from the
very beginning. And for those of us don't care about "typographical
nonsense", forcing them to resubmit hundreds of strings will hardly
change that stance.

Changes to ellipsis characters should probably be applied automatically
as well, except for a few locales (like Japanese), for which Unicode
ellipsis is displayed as three vertically aligned dots, which at least a
couple years back seems to have been very unexpected in application UIs.

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] n’t → n't

2014-11-30 Thread Rimas Kudelis
Hi,

2014.11.30 19:13, Olivier Hallot wrote:
> Lets invent a new language in the world named Liboish - LibreOffice
> language - that in fact is often confused with en_US, but it is not the
> same.
>
> I suggest to create a new entry in Pootle, named en-US so that we get a
> translation from Liboish to English. Other languages translates directly
> from Liboish and we are all happy not to redo our work.
>
> (Apologizes for the inapropriate sense of humour, but I saw this extra
> work comming months ago. 99% of my 4.4 UI was rework)

I can't understand whether or not you're joking, but others are already
voicing their support to this idea, so I'll voice my 'unsupport' as well.

I don't really think this would be viable solution in the long run.
Somebody would have to maintain that "translation" for years just
because in 2014 localizers made a fuss out of a one-time problem that
could (and should) have been automated not to bother them in the first
place. Furthermore, in my opinion, there would be constant risk of
either doing too much or not doing enough in this front.

Let's not forget that massive changes like these don't happen every
month. Yes, we had migration to different accesskey characters, and
manually updating all locales to reflect that must have been painful to
localizers. Yes, this current situation is somewhat similar because
again no real translation would is involved in this massive change. But:
I still believe this migration can be automated and made painless (at
least for the most part), so why not aim for making that automation a
prerequisite of the change that is threatening our well-being? LibO
developers don't live in another planet, and they can be reasoned and
negotiated with, right?

Rimas



-- 
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


Re: [libreoffice-l10n] Re: [libreoffice-l10n] n’t → n't

2014-12-01 Thread Rimas Kudelis
Hi Christian,

2014.12.01 00:32, Christian Lohmaier wrote:
> On Sun, Nov 30, 2014 at 10:16 PM, Olivier Hallot
>  wrote:
>> On 30/11/2014 18:52, Rimas Kudelis wrote:
>>> 2014.11.30 19:13, Olivier Hallot wrote:
>> painless migration was my hope when I raised the issue, but saddly it
>> didn't show up in time. Such Changes In Capital Letters And Semicolons
>> Are Suitebale in EN But Does Not Affect Other Languages Where This Rule
>> Does Not Apply.
> It's impossible to automatically decide which of those changes are
> purely cosmetic and which not.

I'm not sure what you mean here. It can't be hard to distinguish such
lines where only straight apostrophes, straight quotes or
three-dots-as-an-ellipsis are being replaced with their fancier
equivalents. And with these changes filtered out, I don't think it would
be impossible to propagate them to localized files by changing msgid's
in them to reflect these cosmetic updates.

> And there likely won't be anyone who
> manually goes through all the changes and manually creates mapping
> from old to new so that old translations can be pulled in. And with
> changes like changing casing and adding colons it is more likely that
> the translation will also want to apply the change, so just staying
> silent and not flagging the string as changed is not really an option
> here.

I believe we could have cheated even with colons by adding them to the
translations automatically (probably on an opt-out or opt-in basis).  As
for case changes, I guess it depends on their nature: if en-US would
decide to make a massive change between say Title Case and Sentence
case, I guess most locales would find it very much acceptable to just
keep what they already have. On the other hand, if the change was to or
from lowecase, the expectations might differ.


>> Nevertheless, it may be time to create a T/LSC Translation/Linguistic
>> Steering Commitee to address the issues raised here. LiBO does not have
>> a linguistic revision of terms used in the UI.
> Not progressing just for the sake of not causing work for anybody is
> the wrong approach.
> But that doesn't mean the workflow as a whole cannot be improved.

Fully agreed.

> It would for example also be possible to have "master" project in
> pootle (instead of just for the release-branches), so that the amount
> of changes are incremental, and not all one or two months before a new
> major release.
> (but that of course means applying a translation to multiple projects,
> so not sure whether that really reduces the work and not causing more
> work for translators...)

For at least a few years, I performed most of my Mozilla localization
work on their master branch. When branches were cut and repositories
migrated, I would migrate my repos too. I can imagine a scenario where
at least some teams would want to work on LibO master as well. There
even is potential that such process could help avoid some problems by
signaling them early enough so that they can be fixed or undone.

Obviously though, this should not be required from all teams. And if we
have at least two simultaneously active release branches, this might not
be the best approach.

Regards,
Rimas



-- 
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


Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-03 Thread Rimas Kudelis
IMO bad quality of English strings can be improved by having some l10m teams 
work on Master (and spotting these bad strings early enough), and that is being 
discussed in parallel.

Also, perhaps requiring string reviews on patches with new or changed strings 
could be an option. I'm pretty sure we could find someone to gladly do these 
reviews within the community. :-)

Rimas

On 2014 m. gruodis 4 d. 08:06:12 EET, Yury Tarasievich 
 wrote:
>I may be completely misunderstanding this, but 
>it seems to me the point is the en_US strings 
>should be translations as well. That would put 
>much needed damper on the changes introduced 
>"just because they can be introduced". As a 
>secondary gain, translations are (hopefully) 
>created by folks with at least some native 
>language preparation; right now "master" strings 
>"which anybody can write" -- as I know from my 
>own practice and from this list -- may be 
>awkward in expression and/or convoluted in 
>meaning (fixing which creates more work for 
>everybody).
>
>Yury
>
>On 12/04/2014 02:58 AM, Jesper Hertel wrote:
>> 2014-12-01 14:57 GMT+01:00 Sophie :
>...
>>> Some changes are necessary and the en_US version has to be
>maintained
>>> too but that shouldn't have an impact or at least, as limited as
>>> possible on the l10n work.
>> I do believe discussing the English strings are somewhat related to
>the
>> translation of them, so maybe because of that I fail to see a very
>sharp
>> division between them and the localization. The English strings are,
>in
>> principle, also a type of localization, I would say. They just have a
>much
>> higher authority, as they become the authoritative source for the
>rest of
>> the localizations.
>...
>
>Yury
>
>-- 
>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

--
Rimas

-- 
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


Re: [libreoffice-l10n] Cosmetic changes?

2014-12-14 Thread Rimas Kudelis
Hi,

2014.12.14 02:43, jonathon wrote:
> On 13/12/14 21:45, Khaled Hosny wrote:
>
>>> Changes made in one dialect of one language should neither affect, nor
>>> effect changes in other dialects of the same language, much less other
>>> languages.
>> Huh? English (US) is the “source” language, 
> Treating en_US, en_DE, en_UK, or any variant thereof as the "source"
> language is, at best, translation mismanagement.

No. Translation mismanagement was propagating these cosmetic changes to
Pootle without having automatically updated localized Gettext files.

> The more fundamental error is assuming that what is in source is
> consistently en_US, or any other en_* variant.

It should be. You can look at it the other way around: anything that
gets in the source should consistently be en_US, not just
whatever_lingo_the_developer_had_in_mind.

Rimas


-- 
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


Re: [libreoffice-l10n] Cosmetic changes?

2014-12-14 Thread Rimas Kudelis
hi,

2014.12.14 13:48, Olivier Hallot wrote:
> On 14/12/2014 06:59, Rimas Kudelis wrote:
>> It should be. You can look at it the other way around: anything that
>> gets in the source should consistently be en_US, not just
>> whatever_lingo_the_developer_had_in_mind.
>>
>> Rimas
> You're right and that is the way it has to be.
>
> We face the issue that LibreOffice developers are mostly not English
> native speakers, and they are much less often graduated in English
> litterature. Mistakes and poor clarity are introduced in their strings
> quite naturally and often. That is the way it is and we live with it
> since OpenOffice.org.

Which is why I'm advocating string review process, if only it is
possible. It's perfectly normal that some of us have trouble writing
concise  and typographically correct English. But isn't it similar to
writing buggy code? We do have code reviews, where someone else with the
right set of knowledge reviews code patches. So why not have a similar
process for string changes? Why not ask somebody who maybe can't code,
but knows English (including typographical stuff) well to review the
strings that are being changed or newly introduced?

Now that I think of it, if we have UX reviews (and if we don't, we
should), strings might just fall into that category.

> Reviewing en-US is a good thing once in a while, even if it gives us
> more work, and I expect once fixed it will not change anymore.

Reviewing en-US is a good thing for sure. I believe however, that when
we have massive changes, which can be automatically transferred to
localized resources without degrading l10n quality, we should transfer
them automatically (maybe on a per locale opt-in or opt-out basis). What
has been happening lately (and is explained in Michael's examples) is
indeed a major messup (mismanagement, if you like). Few more cases like
this, and LibO will start losing localizers. This thread is a clear warning.

> As a side note, devs don't even write help pages to explain their new
> features, and this doesn't help our translation job too.

Devs don't have to write help pages. However, when others writes these
help pages, they could be the ones raising a flag about string quality
issues.

Rimas


-- 
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


Re: [libreoffice-l10n] Cosmetic changes?

2014-12-15 Thread Rimas Kudelis
Hi,

2014.12.14 15:04, Tom Davies wrote:
> My last "hare-brained" idea was blatantly flawed.  Thanks to Yury (i think)
> and someone else for shooting it down quickly before it went anywhere! :)
> Sorry about that!
>
> It sounds like there is scope for a lot of automation.  There might already
> be ways of doing it.
>
> 1.  Can fuzzy strings be accepted "en masse", preferably by large-scale
> selection?  (I'm guessing there isn't at the moment)
>
> 2.  Is there an "undo"?
>
> 3.  Can individual strings "undo" to get single strings back to being fuzzy?
>
> Also, is there a way of getting an extremely large selection of strings
> grouped in some way so that people can see the whole group had 1 specific
> change?  Even fairly small groupings might help a bit!
>

As far as I know, there is no Undo functionality in Pootle. Once you
submit a string, its old version is gone for good. Same goes for
grouping strings by changes: while this might be an interesting idea, I
don't think it is currently possible in Pootle.

And now to my main point (your first question)

As far as I know, Pootle operates on single strings, not on groups. But
even if it did operate on groups, it would be hard to tell whether or
not a particular fuzzy string should be approved without looking at it,
so it wouldn't really help that much. On top of that, it would still
waste someone's time.

I still believe that the right way to implement typography improvements
(and case improvements in most cases) is to transplant such changes to
localized files invisibly. Ideally, it would be done with a prior notice
such as "please upload all your work by day X hour Y so we can base this
migration on your latest work and none of it is being lost".

Same applies to accelerator character change (~ to _).

Even changes like adding a colon at the end of a string (of which people
also complained) should be ported to most locales automatically,
allowing locales to opt-out if they want to do that manually (although I
guess locales should be allowed to opt-out in all cases anyway).

I don't really follow this mailing list too closely, so I might be
wrong, but I would speculate that perhaps the main reason why we ended
up all whining and pointing fingers and sometimes speaking badly of
other people in this thread is the lack of internal communication,
proper planning and preparation. Someone came up with a great idea to
easily improve a massive amount of source strings, but maybe that person
didn't even consider the amount of workload that such change would bring
to the L10n teams. Someone else liked the idea, but did not consider
L10n as well. I can actually relate quite easily to these people – they
are developers, not localizers, it's quite likely that they don't even
know how our L10n process works. So, they liked the idea, and their
changes hit the fan, splashing "typographical nonsense" on everyone.

Had the plans to change such a big amount of strings been communicated
to the localizers well in advance, a red flag would probably have been
raised, and then better preparation (in the form of automatic conversion
scripts) would have been made in anticipation of these changes. Then
everything would be much smoother and we wouldn't waste our time
repeatedly expressing how annoyed and underappreciated we are feeling.

I guess things like these have to be learnt by developers the hard way.
Which is why it's very important that our dissatisfaction with these
issues is communicated to the dev team properly and that they note it
and don't forget it in future. This is also where at least a few L10n
teams working directly on master would help: noticing such unexpected
massive changes early enough should open the door for backing them out
and delaying their re-landing until necessary preparations would be made.

Anyway, I think I've already said all this a couple times before. Time
to sleep. :)

Cheers,
Rimas


-- 
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


Re: [libreoffice-l10n] Re: Pootle terminology

2014-12-21 Thread Rimas Kudelis
2014.12.21 15:17, Mihovil Stanic rašė:
>
> 21.12.2014. u 13:43, Jesper Hertel je napisao/la:
>> I know it is possible in Pootle to search and edit terminology entries
>> online. (In the Danish project, it happens at
>> https://translations.documentfoundation.org/da/terminology/translate/#filter=all
>>
>> ).
>>
>> I can see that this has not been set up for Croatian (hr); the URL
>> https://translations.documentfoundation.org/hr/terminology/ leeds
>> nowhere.
>>
> Croatian terminology file is located here:
> https://translations.documentfoundation.org/hr/libo_ui/pootle-terminology.po
>
>
> Inside libo_ui directory. Not sure why, but I noticed some other
> languages have it same way.
> Anyway, I don't mind having it that way.

It is this way because you (or maybe someone else) made it that way. The
pootle-terminology.po file inside a translation project holds
terminology that is specific to that particular translation project
(libo-ui in this case) and should not be used in other projects (such as
website, android, libo*_help and other libo*_ui projects). Managing
terminology that way is rather suboptimal for our case, in my opinion,
but the choice is yours.

Meanwhile, the Danish Terminology, to which Jesper pointed, is global to
our Pootle instance. The terms from it will be suggested for all
translation projects within our Pootle.

If you would like to have the Terminology project enabled for Croatian,
just ask. Once it is enabled, you can upload any files you want to it,
and manage them, as Jesper pointed out (although I guess that management
interface is still not as good as it could be).

>>> - would be nice to add translation for new entry in same step,
>>> curently I
>>> can add new entry, then go to language main page, select "needs
>>> translation" in termnology and then enter translation
>>>
>> I didn't understand that. Maybe that is Virtaal related?
>>
>
> When I add new entry to terminology file:
> https://translations.documentfoundation.org/hr/libo_ui/terminology_manage.html
>
>
> I can only add original string, for example word "target" and then
> save it. I cannot add translation "cilj" in same step.
> To add translation, I have to go to main libo_ui directory, select
> "untranslated strings" from pootle terminology file and then translate it.

This looks like a good feature request for Pootle. :)

Rimas



-- 
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


Re: [libreoffice-l10n] Re: Pootle terminology

2014-12-21 Thread Rimas Kudelis
2014.12.21 16:36, Mihovil Stanic rašė:
>
> 21.12.2014. u 15:24, Rimas Kudelis je napisao/la:
>> It is this way because you (or maybe someone else) made it that way.
>> ... If you would like to have the Terminology project enabled for
>> Croatian, just ask.
>
> Robert was active when LO project started, he probably asked for that.
> When I joined few years ago, it was already like that.
>
> Please, make it seperate project then if that will increase it's
> usability.
>
> Mihovil
>

Added a separate project. You can now upload the files you want to it,
and delete the per-project terminology files.

If you don't have global permission for Croatian, just give me your
username, and I'll give them to you.

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Most important folders (Guarani)

2015-01-25 Thread Rimas Kudelis
Hi,

couple questions.

Shouldn't we use the short locale code when it is available (in this case, gn 
instead of gug)?

Also, shouldn't we treat one of the Guarani locales as the base one (that is, 
use only the language code for it, without specifying the region code)? I'm not 
speaking with absolute certainty here, but I only know one exception to this 
rule of thumb so far (Chinese).

Either way, gug-PY looks superfluous: gug already means "Paraguayan Guarani", 
according to ISO 639-3.

Rimas

On 2015 m. sausio 23 d. 16:17:31 EET, Andras Timar  wrote:
>On Fri, Jan 23, 2015 at 2:15 PM, Giovanni Caligaris
> wrote:
>> I am only doing a Paraguayan-Guarani translation.
>
>In this case it would be good to use the specific "gug" language code
>everywhere. I was looking fog "gn" in locale data, that's why I asked
>you, if you have had it submitted.
>
>I can add Guarani translations to the build (to master for the time
>being) in the next days.
>
>Regards,
>Andras
>
>-- 
>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

--
Rimas

-- 
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


[libreoffice-l10n] Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams

2015-01-27 Thread Rimas Kudelis
Hi,

2015.01.26 17:40, Jan Holesovsky rašė:
> Sophie píše v Po 26. 01. 2015 v 16:19 +0100:
>
>> That's why we were thinking of a en_US version as a real language and
>> different from the sources and
> But at some stage this will have to apply to the sources - and at that
> time, it will be even worse than now :-(  I'm afraid having en_US as a
> separate language will make the situation worse, not better.
>
>>  also about scripting changes when
>> possible (like the substitution of ~ by _)
> Sure - so I think this was something that could have been automatized
> with a trivial script; when this was noticed for the first time, please?
> Pity that it was not brought to the ESC as a problem...

I just wanted to say that I'm fully with Jan on these two statements: I
believe that the right thing to do is automation of massive trivial
changes, not a separate pseudo-locale where strings with developer
mistakes and/or without enough clarity would be carved in stone. Having
that pseudo-locale would not help us solve half of cosmetic issues, such
as added colons or changed access keys, these would require scripting
anyway. The issues it would solve are either also scriptable
(typographical or letter case changes) or should be rare by their nature
(typo fixes or sentence improvements; now that some teams work on
master, these should occur in branches even less frequently). On the
other hand, having that source locale would introduce a yet another
level of complexity by forcing each developer to decide where each
string change should go, and if you are thinking about making a single
person or two accountable for these decisions, then why not ask them to
instead review strings that are about to be landed into en-US?

In general, I think it's kind of sloppy (sorry, can't think of a right
word right now) to leave miss-worded strings in the source as they are,
and fix them in a separate locale instead. I don't know how many fixes
like that (specifically excluding typography, colons and similar massive
replacements) end up in each release, but assuming there aren't many
(e.g. a dozen or two), I really don't think they deserve all this fuss.

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

2015-01-27 Thread Rimas Kudelis
Hi Jan,


2015.01.26 16:43, Jan Holesovsky rašė:
> Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:
>
>> Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those 
>> different quote styles I don't even have on my keyboard) and anything 
>> similliar - NOT OK if you don't script it for all languages
>> Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all, 
>> change just for en_us, don't change my strings and don't even notify me 
>> you did it in en_us
> I see 2 problems here:
>
> 1) There is no tool that would detect these trivial changes, and would
>act accordingly.
>
>
> Regarding 1) - I thought that Pootle is detecting the trivial changes
> some way, and offering the original translation.  Is it not?  What can
> be done to improve that, so that for translators it is just a matter of
> checking; not a matter of translating?  [Or even what you suggest - that
> it would just update the source strings without touching the
> translations?]

Pootle does offer the original translation, but the localizer still has
to approve it.

Furthermore, Pootle does not apply any automatic changes. If you had
e.g. "Some ~string", and you change it to "Some _string", Pootle will
show the original translation as a hint, but the user will still have to
port this trivial change to the translation manually.

Needless to say, sometimes these minor differences avoid being noticed
by the localizers, which results in errors in the locale (I've seen
incorrect access key identifiers in the menus at least once).

However, while you are correct that there is no tool to detect these
changes, I don't think there has to be. The person who implements the
change knows better than anyone whether or not it can be automated,
perhaps they even automated it themselves. For example, I seriously
doubt that somebody went over all L10n files and changed triple dots to
ellipses manually, this was most likely a scripted change. Same, or very
similar, script would have probably worked with all other locales, but I
guess that person simply didn't think about it.

Similarly, changes in used quote characters most likely could have been
isolated and transplanted to locales.

Adding colons to certain strings only would probably have been slightly
more difficult, but still scriptable.

And none of that requires any "tool to detect trivial changes"... ;)


> 2) The texts for translations are updated in big 'code' drops, without
>possibility for translators to affect the process in any way - for
>them it is too late.
>
>
> Regarding 2) - I'm glad that you say that the strings will be now
> getting to Pootle immediately after the code / string changes in master.
> I think it is important that the translators will be able to deal with
> the changes immediately, not several months later, so that they can
> cooperate, and not only react.
>
> In general, I don't think that setting extremely strict rules works,
> unless you have means how to enforce them - like via a commit hook or so
> (and it is extremely unpopular way to do things).
>
> It is always much better to communicate - if you see a developer who
> commits a change that causes you grief, please _do_ tell _him/her_
> immediately, and - if possible - in a friendly way.  I'm sure he/she
> will do much better the next time.
>
> Unfortunately I did not see any signs of notice that this or that change
> was problematic for localization on the development mailing list - were
> there such warnings there?  Like "commit XY caused AB - please don't do
> such things, unless we agree how to do that effectively / without pain"?
> Or was it impossible so far because the strings in Pootle were not
> synced with master?

I fully agree with you here, and yes, so far communicating these issues
was really difficult because these massive changes appeared in front of
the localizers' eyes way too late in the process.

Regards,
Rimas


-- 
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


[libreoffice-l10n] Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams

2015-01-28 Thread Rimas Kudelis
Hi Stephan,

2015.01.28 11:20, Stephan Bergmann wrote:
> When talking about (developer-side) scripting, is it actually OK to
> commit modifications to the translations in the translations git
> sub-repo?  My understanding was that such modifications would be
> overwritten by the next "import commit" (as typically done by Andras,
> AFAIU from some Pootle database).

The process as I see it would be somewhat like the following: when we
have a big enough string change, which can be scripted coming up, it
should be announced at least a few days in advance, that on day X time
Y, this change will land. Localizers should be allowed to choose whether
or not they want that particular big automatic change transparently
ported to their locales, with a sane default for those who don't voice
their choice by deadline (I suppose that usually the default should be
to perform the change for them as well).

On day X time Y, we close down the affected Pootle project, push its
localizations into git, then somebody who's in charge checks them out of
git and runs the script. When the script finishes its work, the
resulting files are committed back to git, imported back to Pootle and
the project is re-opened for translation. Once that is done, an
announcement should be sent to the L10n list with huge thanks for
everyone's patience and kudos to everybody involved in the process. And
we all live happily ever after. :)

Possible risks that I came up with:
* The process of exporting files from Pootle or importing them back
might take hours
- I don't expect localizers to be too angry about that, because they
can do other stuff meanwhile (such as enjoy their Real Life or work on
other projects).
* The scripts might be buggy
- Obviously, each time they should be tested in advance with at
least some real data and their result should be validated before committing.
* Some localizers might be too late to the train with their changes
-  Well, first of all, they shouldn't be, but then we could also
have some buffer timeframe to cope with this issue.

On the bright side, I hope the massive changes we are talking about here
will be less and less frequent, making this issue less and less
relevant. From my understanding, we've already changed three dots with
ellipses and straight quotes with curly ones, there shouldn't be much
more typography to improve on, is there? :)

Rimas



-- 
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


Re: [libreoffice-l10n] Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams

2015-01-29 Thread Rimas Kudelis
Hi,

2015.01.29 11:20, Stephan Bergmann wrote:
> On 01/28/2015 08:02 PM, Rimas Kudelis wrote:
>> On day X time Y, we close down the affected Pootle project, push its
>> localizations into git, then somebody who's in charge checks them out of
>> git and runs the script. When the script finishes its work, the
>> resulting files are committed back to git, imported back to Pootle and
>> the project is re-opened for translation. Once that is done, an
>> announcement should be sent to the L10n list with huge thanks for
>> everyone's patience and kudos to everybody involved in the process. And
>> we all live happily ever after. :)
> [...]
>> * The scripts might be buggy
>>  - Obviously, each time they should be tested in advance with at
>> least some real data and their result should be validated before
>> committing.
>
> Yeah, its vital that the script will be run in a way that can be tried
> locally and in advance by any script-writing developer (i.e., that the
> script will ultimately be run on the git data, not on some pootle data).

Yes, when I'm talking about scripting stuff, it must be done on raw git
data.

>> On the bright side, I hope the massive changes we are talking about here
>> will be less and less frequent, making this issue less and less
>> relevant. From my understanding, we've already changed three dots with
>> ellipses and straight quotes with curly ones, there shouldn't be much
>> more typography to improve on, is there? :)
>
> Typographic changes should rarely be scriptable across all locales
> anyway, I guess.  (Even the ellipsis change might not have been, given
> there's not only U+2026 HORIZONTAL ELLIPSIS but at least also U+0EAF
> LAO ELLIPSIS and U+1801 MONGOLIAN ELLIPSIS.)

Furthermore, that's why I emphasized the need to be able to opt out of
the scriptable change: some locales might need different case-by-case
handling than others. But even your example is still easily scriptable,
you just need three (or maybe four) variations of the same script: one
for most locales, one for Lao, one for Mongolian and one for Japanese
(or perhaps all CJK locales).

Rimas


-- 
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


Re: [libreoffice-l10n] Updating against templates

2015-01-31 Thread Rimas Kudelis
Hi,

2015.01.31 13:16, Michael Bauer rašė:
>
> Sgrìobh Christian Lohmaier na leanas 31/01/2015 aig 07:48:
>>
>> I absolutely don't get why you're attempting to use the update
>> against templates from the web.
>>
> Because there have been no new strings in 4.4 and since it has
> happened before that there WERE new strings and the simply weren't
> coming through, I thought I'd 'check'
>>
>> Over and over we have stated that this can lead to intermixed
>> translations and thus people should not use it.
>>
> Well, it's news to me. Perhaps we should change the wording on the
> Check against templates button to 'Don't use this button'
>>
>> So unless you at least state the project and language and reason for
>> running it, I don't want to spend time on that.

Perhaps we should just hide or disable that button if it just messes up
the translation instead of doing what it claims to? :)

Rimas


-- 
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


Re: [libreoffice-l10n] Re: New language Nahualt (nah)

2015-02-10 Thread Rimas Kudelis
Hi Daniel,

2015.02.10 02:50, Daniel Espinosa wrote
> I would like to start, with the help of translators in Mexico, LibreOffice
> Nahuatl translation project. For this project:
>
> Language Name: Nahuatl
> ISO Code: nah
> Microsoft ID: Not found.
> Character Set: ISO/IEC 8859-1
> Currency: MXP
> Date Format: ISO 8601, DD/MM/YY, DD/MMM/
> Numbers as for: es_MX
> Plural form: nplurals=2; plural=(n != 1);
>
> Language information:
>
> A native language spoken in Mexico, with more than 28 variants. Country
> official language is Spanish, then setup Pootle to show existing
> translations in Spanish will help native translators to get work done.

First of all: welcome onboard!

As I can see, you have already registered yourself with Pootle. I've
granted your user (daniel.espinosa) administrator permissions on Nahuatl
(nah). I have also initialized LibreOffice 4.4 UI and Terminology
projects for your language on Pootle, so basically, you can start
working right away. But please read on. :)

It seems (and you wrote it yourself) that 'nah' is the code for a whole
bunch of languages, not a particular one. I don't know how different
they are, but if they are different enough to the level that treating
them as one and translating into "unified Nahuatl" doesn't make much
sense, perhaps you should use a different language code? For your
reference, there is a convenient list of languages with their ISO 639-3
codes in the sidebar here: http://en.wikipedia.org/wiki/Nahuan_languages
. If you think that there is a better suitable code for your language,
please let me know before you start translating, so I can delete nah and
initialize a different language for you.

Once the language code question is resolved, here are some resources to
get you started:
- https://wiki.documentfoundation.org/Translating_LibreOffice (our most
current Localization guide)
- https://wiki.documentfoundation.org/LibreOffice_Localization_Guide
(older Localization guide, mostly obsoleted by the page above)
Also pages linked from:
- https://wiki.documentfoundation.org/Language
- https://wiki.documentfoundation.org/Category:L10n

Finally, please add yourself and your team to the following Wiki page so
that others can find you easily:
https://wiki.documentfoundation.org/Language_Teams

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Make Guarani available

2015-02-20 Thread Rimas Kudelis
Hi, 
Just wondering: why do we need to change  the locale code?

Rimas

On 2015 m. vasaris 20 d. 11:00:49 EET, Andras Timar  wrote:
>Hi Giovanni,
>
>On Fri, Feb 20, 2015 at 1:03 AM, Giovanni Caligaris
> wrote:

 I have sent an email before asking the Guarani pack to be able to
 download.

 They told me they were going to change the local code on pootle
>from Gn to
 Gug but never got done.
>
>Who told you that? I asked Cloph to change gn to gug, but he is rather
>busy.
>
>

 I have reached 33% now, and have completed the sw, sd, sc
>(uiconfig)
 folders and have done some work on other folders.

 I would like to know if there's anything I can do to make the pack
 available.

>
>Guarani is targetted for LibreOffice 4.5. First language packs will be
>available from TDF  with 4.5 betas. See the release plan.
>http://wiki.documentfoundation.org/ReleasePlan
>
>However, you can always build LibreOffice yourself from source code,
>see https://wiki.documentfoundation.org/Development
>We can help you, if you get stuck.
>
>Best regards,
>Andras
>
>-- 
>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

--
Rimas

-- 
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


Re: [libreoffice-l10n] Make Guarani available

2015-02-24 Thread Rimas Kudelis
Thanks Tom, it seems you're right: gn is considered a macrolanguage:
http://www-01.sil.org/iso639-3/documentation.asp?id=grn .

Regards,
Rimas


2015.02.20 16:40, Tom Davies rašė:
> Hi :) 
> My guess would be that there are a lot of variants, as there are with
> English (ie US, vs GB/Uk, vs Aus etc).  The 3 letter code makes it
> specific to the specific language rather than to the generic
> collection of languages. 
>
> Of course it might be that the country has at least 2 different
> languages and the 3 letter-code allows soemone else to translate for
> the other language someday. 
>
> Err, i am not sure if the question was aiming for a much more advanced
> level of understanding or just needed a little nudge like i just gave. 
> Regards from
> Tom :) 
>
>
> On 20 February 2015 at 14:24, Rimas Kudelis  <mailto:r...@akl.lt>> wrote:
>
> Hi,
> Just wondering: why do we need to change  the locale code?
>
> Rimas
>


-- 
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


Re: [libreoffice-l10n] New Guaraní

2015-04-25 Thread Rimas Kudelis
Hi,

2015.04.24 00:45, Giovanni Caligaris wrote:
> Hello
>
> I was wondering if the Terminology folder could also be transfer from the
> old Guarani (gn) to the newer one (gug).

done.

> Also, shouldn't the new name be Paraguayan Guaraní or something along those
> lines? I know that 'gug' stands specifically for Paraguayan Guaraní. The
> language is also spoken in Argentina, Brazil and Bolivia.

Also done.

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] New Language Dictionary/Spelling/AutoCorrect

2015-05-29 Thread Rimas Kudelis
Hi Giovanni,


2015.05.29 19:24, Giovanni Caligaris wrote:
> I would like to have a Guarani dictionary/spelling/autocorrect in the
> future. I was wondering how to do it. Is it different for every OS
> (linux/win/mac)? Is it a Pootle project?

No, these are different projects, which have nothing to do with Pootle.

LibreOffice, just like a bunch of software, uses Hunspell and/or MySpell
(http://hunspell.sourceforge.net/) dictionaries for spell checking. This
is regardless of the operating system in use. Making a spellcheck
dictionary is quite a big task by itself. It seems there is (or at least
has been) a project on SourceForge to create such dictionaries for
Guarani: http://sourceforge.net/projects/guarani/. You may try
contacting the people behind that project to see if they have produced
anything of use. Even if not, perhaps they would be interested in
restarting.

If there is a spellchecker dictionary available for Guarani, with an
acceptable license, it might be possible to convert its files into
MySpell/HunSpell and use them.


Hyphenation dictionaries are another thing: they use a different format
and different data than the spellchecker dictionaries. I know for a fact
that TeX hyphenation dictionaries might be converted to a format
suitable for LibO, but perhaps it's not the only possible conversion. If
there is nothing to convert, such dictionary would have to be done from
scratch.

By the way, hyphenation dictionaries can also be used in other projects
(e.g. OpenOffice, Mozilla)


Autocorrect is a third type of dictionary, which is also different than
the other two. I think creating this dictionary might be the easiest
task of the three: I have written a basic online tool in PHP which could
help you crowdsource suggestions for autocorrect. At least that's what
it does for me.

Hope this helps. Sorry for not posting any links. I hope someone better
familiar with our wiki can post pointers to further relevant information.

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n]

2015-06-08 Thread Rimas Kudelis
Just to make it a bit less confusing, the _ and ~ characters are used to mark 
access keys. Four example, if you see _File or ~File, it means you can access 
that menu command by pressing Alt+F.


On 2015 m. birželis 9 d. 08:53:52 EEST, Martin Srebotnjak  
wrote:
>It is an accelerator, just as tilde, it is used in some dialogs
>
>Lp, m.
>9. jun. 2015 07:39 je oseba "Veneto ABC" 
>napisala:
>
>> Hi,
>> I need a little help, please: what does the symbol "_" added in some
>words
>> to be translated?
>> Thankyou for your answers.
>>
Rimas

-- 
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


Re: [libreoffice-l10n] Where is Venetian project?

2015-06-16 Thread Rimas Kudelis
Hi,

I wouldn't call this weird. I guess Dwayne and his team just decided it
makes more sense for Pootle to do this. I'd guess most localizers only
work on one language, so redirecting to that language automatically
makes sense.


Rimas


2015.06.16 20:06, Michael Bauer wrote:
> I can still see it:
> https://translations.documentfoundation.org/vec/
>
> Though there seems to be a weird redirect in place, when I try to access
> https://translations.documentfoundation.org/
> it automatically redirects me to the last locale I looked at (just
> now, vec, before then, I couldn't get away from gd...)
>
> Dwayne?
>
> Michael
>
> Sgrìobh Veneto ABC na leanas 16/06/2015 aig 17:08:
>> Hi to all.
>> After migration I can't find Venetian project that I started a few
>> week ago.
>>
>


-- 
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


Re: [libreoffice-l10n] Request of 2 words translation for Redmine

2015-12-01 Thread Rimas Kudelis
hi Sophie,

for Lithuanian:

label_history_tab_all: Istorija
label_history_tab_comments: Komentarai


Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Re: Translation and Review rights Nepali (ne_NP)

2015-12-08 Thread Rimas Kudelis
Hello Saroj,

sorry for the delay. You now have the permissions you asked for.

Regards,
Rimas

2015-12-08 16:27, Saroj Dhakal rašė:
> Hello anyone seeing this post ?  Yes and if it is not the right place
> please point to the right place please .
>
> Desperately want translator and reviewer rights to be able to contribute !
>
> Thanks,
> Saroj
>
> 2015-12-05 14:43 GMT+05:45 Saroj Dhakal :
>
>> Hi All,
>>
>> Could you please grant me , translator and reviewer rights ? My profile is
>> here : https://translations.documentfoundation.org/user/sarojdhakal/
>>
>> My profiles in other projects for your reference :
>>
>>- Firefox l10n : http://mozilla.locamotion.org/user/sarojdhakal/
>>- Ubuntu l10n: https://launchpad.net/~lotusnagarkot
>>- Media Wiki l10n: https://goo.gl/Jn31Se
>>
>> We are currently launching a campaign to completely Localize Ubuntu in
>> Nepali and we believe that Libre Office is an important the part of it .
>>
>> Thanks,
>> Saroj
>>
>>


-- 
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


Re: [libreoffice-l10n] New language request

2015-12-08 Thread Rimas Kudelis
Hi Colin,

2015-12-08 16:23, Greater Worcester Land Trust wrote:
> Hello list,
> I read in the FAQ that you post here to request a new language effort.
> I am looking to start work on a Nipmuck localization.
>
> I have two conundrums:
> 1. I have no idea if anyone is even seeing this post, and
> 2. If this really is still the way to initiate a new localization.
>
> Any help on either of those would be great!

Yes, we do see it, and it's still the right way. I have a few questions
for you as well:
1. Have you subscribed to the list that you posted to
(l10n@global.libreoffice.org)?
2. Do you know the correct ISO code for your language? From glancing at
Wikipedia and some links from it, I assume it would be xlo?
3. A provocative one: are you sure localizing something as huge as
LibreOffice into an extinct (at least according to Wikipedia and its
sources) language makes sense?

Regards,

Rimas


-- 
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


Re: [libreoffice-l10n] New language request

2015-12-08 Thread Rimas Kudelis
Hi,

2015-12-08 18:37, Sophie wrote:
> I agree with Christian here, LibreOffice is a very huge project, you
> will have a lot of concepts to define to create the right translation
> and a very long work on the glossary before beginning. If you really
> want to do localization, then try to find a lighter project, maybe like
> Firefox, which have less dialog boxes and globally less strings to
> translate. Or like Chistian said, translating documentation may be an
> alternative to begin.
> In any case, don't feel sad by our reaction, it's really to prevent you
> to waste your time on a project you will never finish, better to begin
> smaller and be happy to see the result than never see it and feel
> exhausted.
> If you need contacts with the Mozilla l10n team in case you're
> interested or other open source teams, let me know, I'll help you to
> reach their communities.
> Cheers
> Sophie

Just a note: while twice smaller than LibreOffice, Firefox is still a
huge project, especially if you want to translate it fully.

Rimas


-- 
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


Re: [libreoffice-l10n] Request proper rights for Pootle

2015-12-15 Thread Rimas Kudelis
Hi Cor,

well, Donné should register himself with the system and tell us his user
name before we can grant him any rights. :)

Rimas



2015-12-15 11:57, Cor Nouws wrote:
> Hi friends,
>
> Donné, ton...@dds.nl, would love to have the proper rights to work in
> Pootle, Dutch.
>
> thanks for helping,
> Cor
>


-- 
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


Re: [libreoffice-l10n] Request proper rights for Pootle

2015-12-15 Thread Rimas Kudelis
2015-12-15 22:36, Cor Nouws wrote:
> Rimas Kudelis wrote on 15-12-15 21:31:
>
>> well, Donné should register himself with the system and tell us his user
>> name before we can grant him any rights. :)
> AFAIK he did. Ah, username Donux. Sorry that I forgot to include that.
>

OK, done.

By the way, don't you have the permissions to manage your team?

Rimas

-- 
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


Re: [libreoffice-l10n] Need for a solid help content

2015-12-16 Thread Rimas Kudelis
Hi All,

+1 on what Michael said about help.  I know that traditionally we've had
inbuilt help for a long time, and I know that some feel like it's really
important, but in my opinion, it's more of an emotional factor and
tradition than real need. I especially don't think that maintaining two
sets of help content (one for wiki, one for inbuilt files) independently
makes any sense, and I surely hope we don't do that. If some of us do
that, well, no offence, but in my opinion they're wasting their time. If
"offline help" is so crucial, can't we provide means to download or wiki
as a generated help file, or as a VM instead?

By the way, Oliver, I don't understand why a particular *type* of help
should be mentioned in an SLA at all. Do they charge differently for
questions covered in built-in help, or what? Would anything in the SLA's
have to change drastically if instead of opening the help file F1 would
open a wiki page in a browser?

Rimas

2015-12-13 21:26, Michael Bauer wrote:
> Olivier,
>
> What you wrote makes sense but seems to talk more about the online
> help rather than the inbuilt help. I can think of several commercial
> and OS tools off the top of my head which do not carry inbuilt help
> these days. Going to Help in Trados for example these days redirects
> you to the online Help whereas in the old days, there used to be
> inbuilt Help. Adobe also redirects to F1 user to online Help. MS
> Office only has vestiges of Help left ("Basic Help" in Word for
> example about using the Ribbon). Anything else you need to hit the
> Microsoft website for.
>
> It may be that inbuilt Help was once the norm but I do not think it's
> going to be the norm for much longer and for obvious reasons
> (maintaining it seems to be a bit of a nightmare, in contrast to
> things like wikis).
>
> Don't get me wrong, I'm not suggesting that we need no form of
> documentation. It's just the inbuilt stuff which I personally feel is
> becoming more of a liability than a useful tool in LO. Perhaps
> other/most users *like* inbuilt Help, I don't know, I do not consider
> myself the arbiter of such things, which is why I said it would be
> nice if some research was done. But I get the feeling Help is shifting
> onto the web more and more and if that is the case and if there are
> good reasons, LO should contemplate this.
>
> Michael
>
> Sgrìobh Olivier Hallot na leanas 13/12/2015 aig 19:05:
>> There is a dimension where documentation get critical, and this is in
>> the enterprise and in the development. A software that does not carry
>> proper documentation is subject to several drawbacks. First, the help
>> desk of the enterprise need to get trained into the issues of
>> LibreOffice in the same way they need to addres MSOffice issues. For
>> that they need to know how the software works to assist the users.
>> Docs and references are crucial, together with proper professional
>> support. Second, the help desk is often charged per call. Enterprises
>> where user cannot find proper doc in their own language is facing a
>> higher TCO, because users call HD to get what they don't have at
>> hand. Third, in the way open source is developed and LibreOffice in
>> particular, there are no specs written in the canonical form a priori
>> before implementation (as it was in the OpenOffice.org times under
>> SUN/Oracle) and this is a choice LibreOffice made to offload all
>> hassle of development and rush into coding improvements long due. The
>> trade-off is a bunch of nice features very few know how to work and
>> the curious take much long time to figure it. Forth, by writing the
>> help pages we have a minimum of a reference guide to address bugs and
>> regressions. Without a reference, a regression is allway harder to
>> understand for the developer and the QA guys. Think about shortcut
>> ABC, that suddenty does not work anymore... how can the developer be
>> sure the sortcut was inded supposed to do what ABC was designed
>> originally So, users may not like the help content as we have
>> today and don't like to press F1, but it is our pursuit of quality
>> software to give them the best we can do in terms of documentation.
>> Admitedly our help system is not a piece of literature easy to read
>> (nor is MS Office too), but it must fullfill the mission to establish
>> the landmark of the sofware behaviour. Yes, "RTFM" comes to my mind
>> actually, but there must be an M somewhere. Finaly, other
>> documentation tools like public forums, books, wikis and even Google
>> are all stars of a documentation constellation but almost never
>> figure in a help desk SLA. As more litterature we produce on
>> LibreOffice, the best, because one of the steepest entry barrier we
>> have to propagate LibreOffice is its lack of culture in the office
>> suite marketplace, something MS already achieved long ago and is
>> extremely hard to displace. Of course, there is room for improvement.
>> The nice part of this is that it is well suited for the
>>

Re: [libreoffice-l10n] Need for a solid help content

2015-12-16 Thread Rimas Kudelis
Hi,

2015-12-16 11:05, Michael Bauer wrote:
>
>
> Sgrìobh Sophie na leanas 16/12/2015 aig 08:56:
>> The help on the wiki is exactly the same as the built in help, it's
>> just an export from what you find on Pootle. 
> Seriously? Yikes...

Michael, look on the bright side: at least it's a single set of
information, not two concurrent efforts.

>> As already said numerous times here, the aim is to have the ability
>> to maintain the help in the wiki and still provide on line and off
>> line help. Not everybody has a connection at low cost, not everybody
>> is allowed to access the internet in his work, etc... For the moment,
>> Olivier, Jay, Lera are working on simplifying the use of the help
>> authoring extension, but it's until the remaining technical problems
>> with the export to the wiki are solved. Cheers Sophie 
>
> *to* the wiki? Shouldn't it be the other way round? I have seen
> in-built Help which was essentially a wiki export but never to date
> the other way round, at least not knowingly.


Well, the goal sounds good to me, and if we're moving towards it, that's
fine. I suppose that the content made available for localization is an
export from the English wiki, right? Otherwise, if the content is being
authored externally, and all wikis are just exports of that external
content, I'd say we shouldn't call them wikis at all.

Rimas



-- 
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


Re: [libreoffice-l10n] Re: [libreoffice-documentation] Help-files: Large-scale 'cosmetic' changes

2015-12-18 Thread Rimas Kudelis
Hi,

2015-12-18 09:59, Jan Holesovsky wrote:
> But - what about to introduce an 'en_US' translation in the Pootle,
> where native speakers could improve the wording without changing the
> meaning?  Then once per the release cycle, these could be copied back in
> a way that it marks no translations fuzzy.

This question keeps popping up, doesn't it...

In my opinion, it's not a good idea.

First of all, I can't see how it helps in the long run: if you plan to
promote the en_US "translation" strings as source at some point, then
they will still be marked fuzzy at that given moment, and you would
still have to tackle that issue either by using some automation, or by
asking all other locales to update their translations. So, the problem
remains there, and the only change is that now you'd have to manage a
new pseudo-translation. And to write a script which promotes these
strings to the base.

On top of that (or if you don't plan to promote en-US strings as
source), I find rather awkward the idea of having "mostly proper
English, but sometimes bastardized by foreign developers" as the base
language. In my opinion, a much better idea would be to hook these
English to-be-localizers into any patch review process which involves
adding new strings. This way incorrect strings would simply not be
introduced into the application, as opposed to being introduced and then
fixed via a weird workaround.

Rimas



-- 
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


Re: [libreoffice-l10n] Pootle server error?

2015-12-22 Thread Rimas Kudelis
Hi,

2015-12-21 15:18, Sophie wrote:
> Le 21/12/2015 13:20, Berend Ytsma a écrit :
>> Is the server error also the reason that Frisian isn't available for
>> translation?
> It's something different, I think Michael has had an issue in creating
> the language. If somebody else with admin rights could have a look, it
> would be great.

I just attempted to do that as well. The language gets "sort of"
created, but it doesn't become available for translation. I was goind to
do an "update from templates", but it seems this feature has been
temporarily removed from Pootle 2.7, and I don't think I have shell
access to the server anymore, so I can't do it the other way.

I'm not sure if this has anything to do with the background job
statistics noting that there are 65 pending and 1 failed jobs, and that
the background job status is stopped. Perhaps that has to be addressed
for Pootle to work properly?..

Rimas


-- 
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



Re: [libreoffice-l10n] Request For Papiamento

2016-02-21 Thread Rimas Kudelis
Hello Ace, and welcome onboard!

I've just granted you (user name acesuares) admin permissions on our pap
project in Pootle. I suppose we probably should treat one of the
dialects of Papiamento as base, you can choose which one. We can add
projects for other dialects whenever feasible.

As you can probably see, we only have Terminology currently enabled for
Papiamento. Other projects can be enabled as necessary, just send a
request to the mailing list. Please also add your team(s) to the wiki
page at https://wiki.documentfoundation.org/Language_Teams, so that
potential future volunteers have a point of contact.

Regards, and have a good ride!
Rimas


2016-02-21 17:23, Ace Suares wrote:
> Dear folks,
>
> Chris Leonard asked me to ask you leadership of the Papiamento team as
> no one is listed on the wiki.
>
> Short background:
>
> Papiamento is a language spoken by the inhabitants of Aruba, Curaçao
> and Bonaire.
> https://en.wikipedia.org/wiki/Papiamento
>
> It's ISO code is pap
>
> There are two different spellings, one for Aruba and one for the rest.
> pap_AW for Aruba,
> pap_CW for Curaçao
> and I propose
> pap_BQ for Bonaire since it has slight, but only very slight
> differences from pap_CW
>
> I did several projects regarding the language:
> - releasing the first Content Management System with a manual and
> interface in Papiamento (in 2003)
> http://www.qwikzite.com/index.php?topic=papiamentu
> - first open source spell checker (in 2011)
> (http://opencuracao.com/2011/09/software-freedom-day-17-sept-2011/)
> - development of locale (since 2012)
> http://www.it46.se/afrigen/export/ooo/pap_CW.xml (might be not the
> latest version!)
> - coordination of translation of Sugar (OLPC) as part of a UNESCO
> funded project (2013) (http://translate.sugarlabs.org/pap/)
> - improving spell checker and locale as part of a UNESCO funded
> project (2015) (URL will follow some day).
>
> Over time, a small team has formed, consisting of Dr Marta Dijkhoff
> (linguist), Mr. Manuel Ortega, Mr. Rendel Rosalia  and me.
>
> For now, it would be great to receive leadership of the Papiamento
> team in Libre Office, I would hope to delegate that role later, and
> also would work to get a team from Aruba on board.
>
> With regards, and open for suggestions or questions,
>
> Ace Suares
>
>
>
>
>



-- 
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


Re: [libreoffice-l10n] Re: Develop hyphenation extension

2016-04-03 Thread Rimas Kudelis
Hello Aleksandr,

2016-04-03 12:16, Aleksandr Andreev wrote:
>> Second question. The character commonly used in Church Slavonic for
>> hyphenation is the underscore, not the hyphen (e.g., hyphe_nation). In
>> TeX, I can simply set the hyphenchar to be _. Is this possible in
>> LibreOffice? If yes, where do I specify it?
> Does anyone know the answer to this question? Can I set the
> hyphenation character to be _ instead of -? Maybe in the locale data
> files? If not, is this a bug against LO or a bug against Hunspell?

I think this belongs to either locale data, as you are suggesting, or
perhaps even to the actual fonts you're using.

The reason why I suspect it might belong to fonts is because there is
only one Unicode codepoint I know of serving this exact purpose (U+00AD
SOFT HYPHEN), and OpenType has a feature called "Localized forms", which
is designed exactly for cases like this (where glyph representation in
particular language is supposed to be different than usual). In
combination, these features seem to provide means to solve your problem.

Rimas


-- 
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


Re: [libreoffice-l10n] Re: Develop hyphenation extension

2016-04-03 Thread Rimas Kudelis
Hi Aleksandr,


2016-04-03 16:17, Aleksandr Andreev wrote:
> On Sun, Apr 3, 2016 at 2:52 PM, Rimas Kudelis  wrote:
>> The reason why I suspect it might belong to fonts is because there is
>> only one Unicode codepoint I know of serving this exact purpose (U+00AD
>> SOFT HYPHEN), and OpenType has a feature called "Localized forms", which
>> is designed exactly for cases like this (where glyph representation in
>> particular language is supposed to be different than usual). In
>> combination, these features seem to provide means to solve your problem.
>>
> You may be right that it belongs to the realm of Font Features
> (although that sounds like a terrible design flaw IMHO, given that LO
> has no mechanism currently to turn simple OpenType features on and off
> IIUC). But it certainly has nothing to do with the Soft Hyphen.
>
> According to the Unicode documentation (p. 268),
>
> Despite its name, U+00AD soft hyphen is not a hyphen, but rather an
> invisible format character used to indicate optional intraword breaks.
>
> And on p. 812 of the Standard:
>
> U+00AD soft hyphen (SHY) indicates an intraword break point, where a
> line break is preferred if a word must be hyphenated or otherwise
> broken across lines. Such
> break points are generally determined by an automatic hyphenator. SHY
> can be used with
> any script, but its use is generally limited to situations where users
> need to override the
> behavior of such a hyphenator.
>
> So, the SHY:
> * has no visible glyph, despite what some font manufacturers are doing;
> * is not a graphic character, but rather a format control character;
> * is not supposed to be used by an automatic hyphenator for hyphenation;
> * is supposed to be used by a user to *override* the behavior of an
> automatic hyphenator.

I see you've done your homework and did a bit more research than me.
Great! :)

With all the data you shared, I'm even more certain that this belongs to
the locale data, much like quotation characters and number formatting
characters. I'm not sure if this locale property is readily available
for inclusion in locale data though. It might be that Slavonic is a very
rare exception to the common rule of using hyphens for that, and that
this hasn't been accounted for anywhere. At least I couldn't find
anything about this neither in the LDML standard, nor in our DTD for
locale definition files
(https://cgit.freedesktop.org/libreoffice/core/plain/i18npool/source/localedata/data/locale.dtd).

Regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Removing old translation projects from Pootle

2016-04-12 Thread Rimas Kudelis
Hello,

I second Kruno.

I really don't think that suggestions from old versions (which were
never approved) are carried onto the newer versions, but I also think
it's hardly justifiable to waste time hunting and carrying them one by
one into the newer branches (not with the typical speed of a heavily
loaded Pootle installation anyway).

Furthermore, just like Kruno wrote, all approved strings are carried
over to the newer branch when that branch gets introduced, so whatever
you lose from your translation, you lose either because the original
string has been changed, or because its identifier has been changed for
some reason, but even then, the original strings will typically show up
as suggestions for the new ones, and regarding the second reason in
particular, that is an infrastructure thing, which should ideally be
resolved by the L10n infra team (or whatever they are called), not the
localizers.

While it's not impossible that some strings might be removed from one
release just to reappear in another one, it's hardly common enough to
justify keeping these old branches indefinitely. On the other hand,
keeping them has some drawbacks as well: it means even more load on
Pootle, and might make an impression that it's worth spending time
updating L10n of these old releases (which it isn't, when the branch is
finalized and no new releases are planned). If you look at our Pootle
homepage (https://translations.documentfoundation.org/projects/), you'll
see that some contributors are still spending their time on 4.3 and 4.4
branches, and for what reason, when these branches are defunct already?
In my strong opinion, time spent on these obsolete branches today is
very much time uselessly wasted. Someone has contributed a change on 4.3
branch as recently as two days ago, and that branch hasn't had a release
for almost a year now. Even if that change was just carried over from
newer branches, it was pretty much pointless waste of time, at least in
my opinion.

All in all, I think these obsolete branches should be removed from
Pootle ASAP, or at the very least made read only.

I would probably even go as far as suggest localization teams to disable
anonymous contributions and any suggestions on all branches but one: the
one on which the team in question actually works and which could later
be morphed into the newer one, when the time comes. This way it would be
easier for incomplete locales to concentrate their effort, instead of
reviewing potentially conflicting suggestions on multiple branches.
Also, this would probably allow to not lose suggestions due to branch
change (although I'm not 100% sure about this).

Regards,
Rimas


2016-04-12 10:13, Kruno wrote:
> On 04/12/2016 05:49 AM, chandrakant dhutadmal wrote:
>> If so, in that case also it would be good to check what translations
>> were done by previous translators.
>
> I sure agree with that but my logic was that older translations get to
> newer versions so they are technically not lost. Translation you find
> 'correct' is included in newer version.
>
> If something is good in 4.4, it's making to 5.1, but if it's not, you
> are still gonna make suggestion that is and so it gets to 5.1.
>
> What's not translated in older, it's not gonna be in newer.
>
> I don't know if Pootle suggesting suggestion from older versions:
> don't know if you can see suggestions that where not approved for 4.4
> when you translating 5.1.
>
> But I do realize that differences in translations for different
> versions can be helpful (for comparing and such) and I'm not trying to
> argue that.
>
> Kruno
>
>
>>  
>>  On Monday, April 11, 2016 2:22 AM, Sérgio Marques
>>  wrote:
>>  
>>   Hi Mihovil
>>
>> For Portuguese you can remove 4.x projects for sure. We won´t touch it
>> anymore.
>>
>> 2016-04-09 10:39 GMT+01:00 Mihovil Stanić :
>>
>>> I see other languages have same projects also, so not sure if you can
>>> remove just ours (HR).
>>> But since 4.3 / 4.4 / 5.0 aren't used any more I think it's safe to
>>> remove
>>> it for everyone?
>>>
>>> Best regards,
>>> Mihovil
>>>
>>> 08.04.2016 u 10:07, Kruno je napisao/la:
>>>
 Hi,

 I wonder if it's possible to remove old LO versions from Pootle for
 Croatian. We still have 4.3 and 4.4 so Pootle is suggesting
 translations
 from this projects as well but those suggestions are often outdated or
 wrong and seeing them in suggestion filed can be quite confusing and
 unnecessary.

 (And how helpful translation from 4.3 can be for translating master
 when
 everything from 4.3 already is in master, and we are just being
 suggested
 something we corrected)

 Thanks,
 Kruno


>>> -- 
>>> 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.

Re: [libreoffice-l10n] Removing old translation projects from Pootle

2016-04-14 Thread Rimas Kudelis
Hi Christian,

2016-04-14 12:47, Christian Lohmaier rašė:
> I removed Spanish, Portuguese and Croatian from 4.3 and 4.4 projects.

 can you share the rationale for leaving these projects in Pootle at all?

Rimas


-- 
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


Re: [libreoffice-l10n] 4.3 and 4.4 projects removal from Pootle

2016-04-18 Thread Rimas Kudelis
2016-04-18 18:56, Sophie rašė:
> Hi all,
>
> To help Christian doing this once instead of a per language basis, who
> is willing to have 4.4 and 4.3 projects removed from Pootle? Please, add
> your language in this thread:

Hi Sophie,

why not ask who wants it kept instead (so that I'd know whom to frown
upon). :)

Rimas


-- 
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


Re: [libreoffice-l10n] 4.3 and 4.4 projects removal from Pootle

2016-04-19 Thread Rimas Kudelis
2016-04-18 18:56, Sophie wrote:
> Hi all,
>
> To help Christian doing this once instead of a per language basis, who
> is willing to have 4.4 and 4.3 projects removed from Pootle? Please, add
> your language in this thread:

I think LT should go.

Cheers,
Rimas

-- 
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


Re: [libreoffice-l10n] 4.3 and 4.4 projects removal from Pootle

2016-04-19 Thread Rimas Kudelis
2016-04-20 08:10, Rimas Kudelis rašė:
> 2016-04-18 18:56, Sophie wrote:
>> Hi all,
>>
>> To help Christian doing this once instead of a per language basis, who
>> is willing to have 4.4 and 4.3 projects removed from Pootle? Please, add
>> your language in this thread:
> I think LT should go.

Sorry, apparently, not. Please disregard my message above.

Rimas


-- 
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


Re: [libreoffice-l10n] [PROPOSAL] New project for dictionaries

2016-04-25 Thread Rimas Kudelis
Hello Dennis,

2016-04-25 13:13, Dennis Roczek wrote:
> <...>
>
> The TL;DR version: Provide a central place for dictionaries maintainers
> including useful tools plus a possibility for easier collaboration.
>
> <...>

I think the idea is awesome. One of the programs I localize currently
maintains its own list of dictionary URLs in XML format, and these point
to OOo mirrors, which I suppose are slowly going into oblivion...

Since Hunspell (with a few exceptions, I know) is pretty much the
de-facto spell checker in today's open-source applications (and not just
them), I think it may be beneficial to have a central repository to host
these dictionaries. Perhaps it would even make sense to adopt one of the
package formats as proposed/official, and then begin getting in touch
with application developers, suggesting that they adopt support for it.
Possibilities here are endless, for example, the repository could
(should) provide a generated listing of these dictionaries in some
pre-agreed format, so that application developers could parse it
automatically and allow users to download desired dictionaries and
install them without ever opening their browser. TDF might indeed be a
good candidate to host such repository.

Rimas



-- 
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


[libreoffice-l10n] Deployment story

2016-07-13 Thread Rimas Kudelis
Hi!

Just noticed this on my Facebook wall:  according to this article [1],
Lithuanian police has migrated from Microsoft Office to LibreOffice on
July 1st.

Woohoo! :)

Rimas

[1]
http://www.alfa.lt/straipsnis/50051682/lietuvos-policija-pereina-prie-atviro-kodo-programines-irangos



-- 
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


Re: [libreoffice-l10n] Deployment story

2016-07-14 Thread Rimas Kudelis
2016-07-13 16:46, Rimas Kudelis wrote:
> Hi!
>
> Just noticed this on my Facebook wall:  according to this article [1],
> Lithuanian police has migrated from Microsoft Office to LibreOffice on
> July 1st.
>
> Woohoo! :)
>
> Rimas
>
> [1]
> http://www.alfa.lt/straipsnis/50051682/lietuvos-policija-pereina-prie-atviro-kodo-programines-irangos

Oh, and here's the official PR from the police itself:
http://www.policija.lt/index.php?id=38492 .

Rimas

-- 
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


Re: [libreoffice-l10n] [HEADS UP] Community forum/askbot linked to LibreOffice

2016-08-23 Thread Rimas Kudelis
Hi,

2016-08-22 18:41, Olivier Hallot wrote:
> The next LO 5.3 release will include a new entry in the applications
> help menu, "Get Help Online".
>
> Menu *Help -> Get Help Online*
>
> This entry aims to quick-link the software to a website with a
> community-driven contents localized website , such as a forum or askbot,
> to be open in the browser. The link will pass the language of your UI
> (not the locale!) to the TDF infra hub.
>
> IMPORTANT: this entry does not link to the wikihelp
> (help.libreoffice.org), which is accessed by menu *Help -> LibreOffice Help*

may I suggest to reevaluate names of these menu entries? When put next
to each other, they seem like pretty much equivalent. I think "Support
forum" would be a more appropriate name for the first one.

Cheers,
Rimas


-- 
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


Re: [libreoffice-l10n] Fwd: Adding a new language: szl (Silesian)

2016-08-28 Thread Rimas Kudelis
Hi Gregory,

I can add the language. Which one do I go with: szl_PL or just szl? Is
there enough in common between Czech and Polish variants to justify
having one of them as the base one?

Regards,
Rimas

2016-08-28 23:17, Gregory Kulik wrote:
> Hi, could I get any answer for this? I'm starting to doubt it reached
> the mailing list. :)
>
> Thank you!
>
>  Forwarded Message 
>
> Subject: Adding a new language: szl (Silesian)
> Date: Sun, 21 Aug 2016 13:14:24 +0200
> From: Gregory Kulik 
> To: l10n@global.libreoffice.org
>
>
>
> Hi,a few days ago I filed a bug requesting an addition of Silesian
> (szl-PL specifically). Because I don't know if it shows up on Pootle
> automatically after that, I'd like to ask to add Silesian (szl). It
> might be necessary to add two varieties: szl-PL and szl-CZ because of
> the majority language influences in the respective countries.
> Plurals same as Polish:
> nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 ||
> n%100>=20) ? 1 : 2);
>
> Thank you!



-- 
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


Re: [libreoffice-l10n] Fwd: Adding a new language: szl (Silesian)

2016-08-29 Thread Rimas Kudelis
Hi Gregory,

I've added szl to Pootle and to Terminology and LibreOffice Master UI
projects.  You are now the administrator for this language. If you want,
I can also add a list of special characters for use in translations,
which might not be available for easy entry using the keyboard. For
example, in Lithuanian, we have this list of such characters:

„“–…←↑→↓

CC'ing Christian Lohmaier, in case anything else has to be done with the
language.

Cheers, and happy translating!
Rimas


2016-08-29 11:19, Gregory Kulik wrote:
> Hi Rimas,
>
> Thank you for the reply. The differences between the variants are
> minor and they are perfectly mutually intelligible. It's just that
> certain suffix patterns are different and the ones we use in everyday
> speech might seem kind of odd for the Southerners. Nevertheless around
> 90% Silesian-speaking Silesians use the szl-PL patterns, so it might
> be fair to use them as szl, especially that all Silesian translations
> on Launchpad, Transifex and everywhere else are just szl and they are
> maintained by szl-PL speakers.
>
> Best regards,
>
> Gregory
>
>
> On 29.08.2016 06:56, Rimas Kudelis wrote:
>> Hi Gregory,
>>
>> I can add the language. Which one do I go with: szl_PL or just szl? Is
>> there enough in common between Czech and Polish variants to justify
>> having one of them as the base one?
>>
>> Regards,
>> Rimas
>>
>> 2016-08-28 23:17, Gregory Kulik wrote:
>>> Hi, could I get any answer for this? I'm starting to doubt it reached
>>> the mailing list. :)
>>>
>>> Thank you!
>>>
>>>  Forwarded Message 
>>>
>>> Subject: Adding a new language: szl (Silesian)
>>> Date: Sun, 21 Aug 2016 13:14:24 +0200
>>> From: Gregory Kulik 
>>> To: l10n@global.libreoffice.org
>>>
>>>
>>>
>>> Hi,a few days ago I filed a bug requesting an addition of Silesian
>>> (szl-PL specifically). Because I don't know if it shows up on Pootle
>>> automatically after that, I'd like to ask to add Silesian (szl). It
>>> might be necessary to add two varieties: szl-PL and szl-CZ because of
>>> the majority language influences in the respective countries.
>>> Plurals same as Polish:
>>> nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 ||
>>> n%100>=20) ? 1 : 2);
>>>
>>> Thank you!
>>
>>
>



-- 
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


Re: [libreoffice-l10n] Hungarian - adding Old Hungarian

2016-08-29 Thread Rimas Kudelis
Hello Tamas,

since you're planning to use automatic transliteration from Hungarian
Latin locale into Hungarian Rovas using an application external to
Pootle, I won't be setting up any projects for your locale in Pootle,
because it makes very little sense to use it just for the submission
process.

You should be able to download Hungarian .po files by navigating to
https://translations.documentfoundation.org/hu/libo_ui/ and selecting
"Download for offline translation" on the right, or (which is probably
even better) by checking out complete "translations" project from git:
https://cgit.freedesktop.org/libreoffice/translations/ (clone URL's are
at the bottom of the page). Once you have applied your transliteration
magic and confirmed that it works well, you should consult Andras Timar,
with whom I believe you're already in contact, regarding further actions.

Regards,
Rimas


2016-08-29 13:22, Rovás Infó rašė:
> Hi developers,
>
> I would like to start a translation project.
>
> The Libreoffice will support the Old Hungarian from 5.3.0, so we should
> prepare the localization for translation.
>
> Language code: ISO 15925: Hung
>
> Libreoffice: Old Hungarian (Hungarian Rovas) [hu-Hung-HU] is on the
> language list,
>
> The script is Right-to-left direction, Unicode area: U+10C80–U+10CFF
> 
>
> Three letter ISO 639-3 code: ohu
>
> For Hungarian users, there are two ways:
>
> - *Hungarian-latin:* the user interface remain latin based (Hungarian
> (latin)), so there is no translation task. In this case the user can select
> the Rovas for writing, by selecting CLT (Old Hungarian).
>
> - *Hungarian rovas:* the user interface will be also based on Hungarian
> (rovas), so there need a translation (precisely transcription) from
> Hungarian (latin) into Hungarian (rovas). We have a translation solution to
> translate quickly, but I would need tables for bulk translation (CSV,
> whatever).
>
> The situation is similar to Serb languege, where there are two writing
> system.
>
> Thank you in advance,
>
> Tamas Rumi
>
>
>
>



-- 
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


Re: [libreoffice-l10n] Adding "Website" to localization

2017-02-21 Thread Rimas Kudelis
Hi,

2017-02-16 18:33, Veneto ABC wrote:
> Could you add "Website" part to venetian localization, please?
> Thanks a lot.

sorry for the delay, I've just added it. It will take some time to
update from templates though.

Bear in mind though that this part is not about translating the website
per se, but only some of its parts. If you want to have a fully Venetian
website, you will have to not only translate these parts, but also have
a separate website created for you and fill it with content.

Best regards,
Rimas


-- 
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


Re: [libreoffice-l10n] Fixing new spell out numbering styles in LibreOffice 6.1

2018-05-03 Thread Rimas Kudelis

hi,


2018.05.03 19:57, Németh László rašė:

Hi,

LibreOffice 6.1 will support “spell out” numbering styles of OOXML (One,
Two...; First, Second..., 1st, 2nd...),
as you can see in the following screen cast (only English, French and
German examples):

  https://youtu.be/c0j4Sjie8t4 

My questions to the native language speakers:

1. Are these numbers correct in your language?

You can check here, too: https://numbertext.github.io/
index.html#testimonials


Lithuanian seems quite OK.


2. Do we need to change the default format etc. according to the normal
usage of your country/language variant?

For example, in the recent implementation, British English and American
English differ with the “and”

101 -> “One hundred and one”: en-AU, en-GB, en-IE, en-NZ
101 -> “One hundred one”: en-US etc.


Not sure which format is the default.


3. Is it enough to support only a single gender in Spanish etc. languages
to cover common outline and page number usage in publishing?

Book/Part/Chapter/Section/Page/Paragraph One, or simply One (normal usage
in English outline numbering)
First Book/Part/Chapter/Section/Page/Paragraph (less common in English, but
default numbering styles cover this, too)

Note: there is a plan to use similar spell out formats in currency and date
formats of Writer, typical in contracts and invoices in several
languages. These formats are only supported in Calc yet by the NUMBERTEXT
Calc extension (or also in Writer macros via the new
com.sun.star.linguistic2.NumberText
service).


Not sure if these questions only apply to Spanish or not. I would 
certainly think it's best to support all possible genders.


Also, I noticed that two ways of spelling out are currently not 
supported for Lithuanian (Year and Formal number, whatever that is).


Also, the default currency is incorrect for Lituania. We switched to 
Euro a few years ago, but the library default is still LTL. This should 
definitely be changed, unless it's not that library, but some other...


Cheers,
Rimas

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


Re: [libreoffice-l10n] Wiki page for LibreOffice localization "language teams"

2010-10-12 Thread Rimas Kudelis

2010.10.12 04:33, Kazunari Hirano rašė:

OK, now, I would like to propose a wiki page for LibreOffice
localization "language teams"

http://wiki.documentfoundation.org/Language_Teams

If we agree on this name of the wiki page, then I will create it.


+1 from me.


Next I would like to hear your opinions and ideas about contents of
the wiki page.

At first I will create the wiki page, based on the following page.
http://wiki.services.openoffice.org/wiki/Languages
You can see table items such as Language, IUT Code, MS Locale ID, MS
Locale ID (hex), ISO code, Symbolic, Environment Variable, Responsible
person, etc.

When I was helping maintain this page, I was wondering if we need all
these items, or if we need more.


I don't think columns 2,3,4,6,7,11 are very useful. If MediaWiki allows 
hiding certain columns with a possibility to unhide them, I think we 
could certainly make use of that feature.



The aim of the "language teams" wiki page is:
1. Any people who want to use LibreOffice in their native language and
to help localize LibreOffice can visit the page and find out who to
contact, which site to visit to get info in their language.  If they
don't find their language on the page, they can add their language to
the page.
2. Any developer who want to build their language version of
LibreOffice can find necessary language info and locale info to build
install sets and language packs.


2. is quite an edge case IMO.

Rimas


--
To unsubscribe, e-mail to l10n+h...@libreoffice.org
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted.



Re: [libreoffice-l10n] Wiki page for LibreOffice localization "language teams"

2010-10-12 Thread Rimas Kudelis

2010.10.12 16:00, Kazunari Hirano wrote:

2. Any developer who want to build their language version of
LibreOffice can find necessary language info and locale info to build
install sets and language packs.

2. is quite an edge case IMO.

You are right.  I have made it very simple.
http://wiki.documentfoundation.org/Language_Teams


Thanks!

Do we really have a Klingon team or is it just a joke? :-O

Rimas


--
To unsubscribe, e-mail to l10n+h...@libreoffice.org
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted.



Re: [libreoffice-l10n] Wiki page for LibreOffice localization "language teams"

2010-10-13 Thread Rimas Kudelis

2010.10.13 09:02, Kazunari Hirano rašė:

Aligato kHirano San!

Douitashimashite! (You are welcome!)


I created a page for Lao!

ArigatouGozaimasu! (Thank you!)


Perhaps if I'm subscribed to this list long enough, I'll be able to 
watch Naruto without English subtitles... :)


Keep it going!

Rimas


--
To unsubscribe, e-mail to l10n+h...@libreoffice.org
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted.



Re: [libreoffice-l10n] change names for Writer and other components?

2010-10-15 Thread Rimas Kudelis

2010.10.15 13:08, Lior Kaplan rašė:

On Fri, Oct 15, 2010 at 7:39 AM, fyva  wrote:


What about changing names for Writer, Calc ... ? If you are going to change
them, then maybe take a name more easily pronouncable for "Writer", such as
Mot or Literato?


I'm not sure it a good idea to change the programs' names. I think there's
enough confusion and we don't need to add more.

my 2 cents...


agreed.

Rimas

--
To unsubscribe, e-mail to l10n+h...@libreoffice.org
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted.



Re: [libreoffice-l10n] change names for Writer and other components?

2010-10-15 Thread Rimas Kudelis
2010.10.15 21:20, Milton Gallegos rašė:
> Writer, Cal and others names are trademarks, aren't?
> Are you sure there wouldn't be any legal issue?

I don't think component names are trademarked.

Rimas


-- 
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Which TransTool ?

2010-10-26 Thread Rimas Kudelis

2010.10.26 14:37, Cor Nouws rašė:

Hi all,

Some years ago I worked with Omega-T on Win.
Now on Ubuntu I see many choices, among them GTranslator and Omega-T.

Which to choose for a quick start? (- dangerous question)


It's very much a question of personal taste, as you could guess.

My current favorite is Virtaal.

Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Status on pootle

2010-11-01 Thread Rimas Kudelis

2010.11.01 08:57, André Schnabel rašė:

Hi,

Am 01.11.2010 01:20, schrieb Olivier Hallot:


just 2 small issues:
Can we have Brazilian Portuguese as language for LibreOffice


done. Problem here is that pootle uses pt_BR as langcode, but our 
filesystem has pt-BR ... we need to think about this in the future.


Pootle 2.1.2 has relaxed the rules for language codes.
Alternatively, you can edit the database manually or patch 
local_apps/pootle_app/admin.py by commenting out the topmost IF-statement:
#if not self.cleaned_data['code'] == 'templates' and not 
langcode_re.match(self.cleaned_data['code']):
# raise forms.ValidationError(_('Language code does not follow the ISO 
convention'))

you can then add the languages to the list and undo your edits. ;)

Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Status on pootle

2010-11-01 Thread Rimas Kudelis

Hi André,

please make me (rq) an admin of Lithuanian on Pootle.

Thanks!
Rimas

2010.10.31 23:04, André Schnabel rašė:

Hi all,

short update - server is ready for testing at
http://pootle.documentfoundation.org/

you may register yourself, but need to ask here for admin or language 
admistration permission.


We only have the lo-build.po files at the server for the moment - and 
these are not the latest files (checkout from yesterday).

So it's really just for testing!

Po files and user accounts might be deleted within the nexts week (but 
I think, we can at least leave the user accounts in place).


So - if you want to have a look, please register a user and test :)

André




--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Confusion br and pt_BR on the pootle server

2010-11-02 Thread Rimas Kudelis

2010.11.02 19:32, André Schnabel rašė:

Am 02.11.2010 10:40, schrieb droui...@drouizig.org:

On the pootle server it seems to be confusion between br or br_FR, iso
code for Breton language and pt_BR, Brazilian Portuguese. The lo_build
file for br code is the pt-BR file.

Is it possible to fix it ?


Ok, this is fixed for now - but seems as if pootle will pick up 
"pt_BR" again if you force it to scan for new project files.
Unfortunately you then can delete pt_BR file from your project, but 
this will also delete the physical file (which is owned by people from 
Brazil).


For the moment I'd recommend to be *very* carfully. With this.


Hi André,

on the brighter side, I can say that this is a known bug in the last 
release, and I think it's already fixed in Pootle's source repo, and 
will be a part of the next release.


We will switch from gnu-style file names to "directory per language" 
after 3.3 - we need to analyze then, how pootle will bevae in that case.


Was that already planned, or is this bug the reason?

Rimas



--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Editing rights on Pootle

2010-11-03 Thread Rimas Kudelis

2010.11.03 15:14, Alexander Thurgood rašė:

Hi Andre,


Le 03/11/10 13:45, Andre Schnabel a écrit :

This might be done by asking here .. or the language maintainers as
listed at http://wiki.documentfoundation.org/Language_Teams


OK, so consider this a request for editing permissions. A long time ago,
I worked with Sophie on translating the strings for the French version
of OOo, when Sun first agreed to letting the French N-L community in to
help, using the Sun XLIFF translation machine tool, and have worked on
other PO translation projects (BKChem for one), so I'm not a complete
newbie to the scene ;-)



I think you should ask the language lead, which is Sophie in this case.



An example in the terminology files :

Well .. regarding terminology files, I would not suggest to allow
editing in general. There should be some coordination at language
teams. Currently the terminology files are some standard files,
not really related to LibreOffice or OOo. How to use these files
should be discussed per language team. (E.g. I would not expect
the German team to use this terminology but establish it's own
file instead.)


I wonder where those files came from by the way (as in, how they were 
generated for Pootle). I've noticed at least one term in Lithuanian 
terminology file that I would NOT use, and most other FLOSS localizers 
don't (this includes OOo/LibO).



Hmm OK. My thoughts on the matter would be why have these files then, or
rather why make them available on the server, if they are not to be
edited, and if they are not really linked to LibreOffice or OOo ? Just
seems like extra space taken up for no reason to me, but then perhaps I
have misunderstood the intention behind them. Usually terminology is
useful for translators to have, so that there is a form of standard
reference, that can be looked up, or even (depending on how things are
set up) used as suggestions for the main work to be translated. If the
terminology reference is screwed up then obviously relying heavily on it
to assist in translation is not a good thing IMHO, and can lead to some
very strange results.


I think what André meant to say is that perhaps before editing those 
files, those changes should be discussed with your language team. I 
don't think they should be read-only, and you guessed well what these 
files are used for – hints.


Regards,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: RE : Re: [libreoffice-l10n] Editing rights on Pootle

2010-11-03 Thread Rimas Kudelis

Hi Sophie,

2010.11.03 15:58, Sophie Gautier rašė:

Hi Alex
I'll grant you the rights as soon as I've access to the server (i'm on a
smartphone currently).
Concerning terminology it's just a test because we have a glossary that i'm
maintaining and i'll upload it on my server once updated with LibO.
Kind regards
Sophie


I think you could also convert that glossary to .po format and overwrite 
the current French terminology file with it. I think that would make 
sense. We would just have to keep in mind that Update from Templates 
should never be used on the Terminology project (though it doesn't seem 
to make much sense to do so anyway). I think your team would really 
benefit from the right terminology being in place, because, as mentioned 
before, it's then being used for suggestions.


Andre, what do you think about it?

Rimas



--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Catalan (Valencian) translation

2010-11-03 Thread Rimas Kudelis

Hi Pau,

2010.11.03 16:22, Pau Iranzo rašė:

Hi André,

El dc 03 de 11 de 2010 a les 09:43 +0100, en/na Andre Schnabel va
escriure:


How can I upload the files? On
http://pootle.documentfoundation.org/pootle/ca_XV I can't see the
"projects" (Is it me who has to create them? How?). There is no page
like http://pootle.documentfoundation.org/pootle/ca_XV/libo33/ ...

I created the libo3.3 project for ca_XV now, so you should be able
to upload the file.



I've been trying to upload the file but the server returns this error:

Server Error

An error has occurred. Thank you for your patience.

Invalid GNU-style file name: ca_XV.po. It must match 'ca_XV.po'.


The file I'm trying to upload is attached to this email. I can't figure
out why this is happening... I haven't modified the original Catalan
file, I just changed the emails and the language name at the beggining
of the file. I tried also with the original Catalan file without
modifications, but the result was the same.


It seems you either did not attach the file or it got stripped by the 
mailing list software without any additional notification.


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Catalan (Valencian) translation

2010-11-03 Thread Rimas Kudelis

2010.11.03 16:55, Pau Iranzo rašė:

Hi Rimas,

It seems you either did not attach the file or it got stripped by the
mailing list software without any additional notification.



It seems it got stripped by the mailing list. Here it is:
http://dl.dropbox.com/u/120126/ca_XV.po


OK, I think I know why this happens, will try to solve it later in the 
evening.


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Fixing the original English strings

2010-11-03 Thread Rimas Kudelis

2010.11.03 17:04, Andre Schnabel rašė:

I've found some inconsistent English strings that I'd like to fix. But
I thought I would ask here first since I don't really know how our
translation framework works.

fine with me, as long as it affects the lo-bild.po files only.

If we speak about strings that are covered by OOo translations - please do
*not* do massive changes.
We do not have a translation process in place. So you would change from
"inconsistent english but localized" strings to "consistend english but
non-localized" strings.

please let's wait with such changes for 3.4 (or the time we know how to
handle full translations).


I think this should be reported in our bug tracker, whenever we have one.

Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Catalan (Valencian) translation

2010-11-03 Thread Rimas Kudelis

Hi Pau,

your file is now in place! You should be able to edit it from now on.

Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Administration rights for Catalan in Pootle

2010-11-03 Thread Rimas Kudelis

2010.11.03 20:05, Jesús Corrius rašė:

Hi Andre, labas Rimas,

Can my user (jcorrius) get administrative rights for the Catalan
language in Pootle?

Many thanks / labai aciu



Of course. Enjoy! :)

Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Catalan (Valencian) translation

2010-11-03 Thread Rimas Kudelis

2010.11.03 20:05, Rimas Kudelis rašė:

Hi Pau,

your file is now in place! You should be able to edit it from now on.


And the upload problem has now been solved too.

Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



[libreoffice-l10n] Easier input of special characters in Pootle

2010-11-03 Thread Rimas Kudelis

Hi folks,

there's something I wanted to let you know. :)

One of the areas where Pootle can make our lives a bit easier is input 
of special characters (see 
http://img255.imageshack.us/img255/4665/pootlespecialchars.png for an 
example). For a few locales (e.g. Chinese), Pootle authors have 
predefined some of these characters, but for most, a Pootle 
administrator has to define them.


So if your locale has any special characters that you cannot comfortly 
type using your keyboard and that you would like to have in the Pootle 
UI for easier access (where you can just click a character for it to be 
inserted), don't hesitate to ask here. It is possible.


Cheers,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] OpenOffice translation files

2010-11-05 Thread Rimas Kudelis

Hi Pau,

2010.11.05 15:32, Pau Iranzo rašė:

But when it comes to OpenOffice.org (and now LibreOffice) even if there
is Catalan (Valencian) translation, it doesn't identify itself as a
c...@valencian but ca_XV, so the system can't recognize it and won't use
it. I don't have the technical knowledge to find out if there is a
workaround or other kind of solution for this.


Try to adapt the solution from here:
http://www.mail-archive.com/debian-u...@lists.debian.org/msg477907.html

It didn't seem to work for me though, but I remember there was a time 
when Russian was set up as a fallback for Lithuanian in one distro, and 
it worked, so I think it is possible.


also, as a workaround, you should be able to use a command like this:

LANG=ca_XV LANGUAGE=ca_XV LC_ALL=ca_XV libreoffice

Hope this helps,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] OpenOffice translation files

2010-11-05 Thread Rimas Kudelis

Hi Pau,

2010.11.05 15:32, Pau Iranzo rašė:

But when it comes to OpenOffice.org (and now LibreOffice) even if there
is Catalan (Valencian) translation, it doesn't identify itself as a
c...@valencian but ca_XV, so the system can't recognize it and won't use
it. I don't have the technical knowledge to find out if there is a
workaround or other kind of solution for this.


Try to adapt the solution from here:
http://www.mail-archive.com/debian-u...@lists.debian.org/msg477907.html

It didn't seem to work for me though, but I remember there was a time 
when Russian was set up as a fallback for Lithuanian in one distro, and 
it worked, so I think it is possible.


also, as a workaround, you should be able to use a command like this:

LANG=ca_XV LANGUAGE=ca_XV LC_ALL=ca_XV libreoffice

Hope this helps,
Rimas

P.S. I wonder why we can't have a proper locale code for Valencian 
though. Does anyone know? I don't think the file format would have 
anything to do with that...


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Translation of extensions

2010-11-08 Thread Rimas Kudelis

2010.11.08 11:45, Andre Schnabel rašė:

Hi,



Von: Kálmán „KAMI” Szalai
Gesendet: 06.11.10 14:07 Uhr
Are you interested to translate extensions that could be enabled via
LibO build environment? I created a workflow to convert properties files
to po then back. Lets discuss the possibilities and if you are commited
to translate such extensions I will publis scripts, and the converted po
files.

I think, we can just ask extension developers to use our "framework" for
extension translation. Means:

- you publish your scripts
- extension developers use your scripts to create po files
- extension developers can then get an own project at our trasnaltion server
   (we need to have a look, how templates can be handeled at pootle)
- extension developers upload their templates
- our translators actually do the translation
- extension developers grab existing translations and include it in their
   extensions

Criteria for us to let them use our framework:
  -the extension must be Free Software and working with LibreOffice


Actually, assuming that "properties files" actually mean "Java 
.properties", there's no need to convert anything. Pootle supports 
.properties files internally. And in this case, filename.properties will 
act as a template for filename_locale.properties files.


I would probably suggest that all extensions would be stored in a subdir 
(of extensions/?) so that we don't end up with a really big amount of 
projects visible on Pootle's frontpage. On the other hand, it's probably 
not desired to have them all as one big project (so that e.g. updating 
from templates would update all extensions at once). Note to self: 
investigate available options.


Regards,
Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] extensions' properties files -> PO -> properties files workflow

2010-11-08 Thread Rimas Kudelis

Hi Kálmán,

2010.11.08 14:03, Kálmán „KAMI” Szalai rašė:

For our extensions I have created a workflow to translate extensions'
dialog. To achieve this I created two scripts to convert files to PO
then convert back the translated files. Are we interested in such
workflow to make extensions available to all supported languages? I
would be glad to help our localization efforts. Currently I can provide
po files for all supported extensions and you can put them to Pootle. Or
do you have better idea? Lets discuss it.


there's already a discussion (started by yourself) in another thread. Do 
you want me to forward that to you or did you intentionally start a new 
thread?


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] localization bug

2010-11-09 Thread Rimas Kudelis

2010.11.09 11:29, Andrea Pescetti rašė:

Martin Srebotnjak wrote:

Also, could we please get a localized license file for localized LO (OOo
didn't want it either)? Just can't find a bug, it was probably closed as
"will never happen".

Actually, it was not OOo; it was, and still is, the Free Software
Foundation. http://www.gnu.org/licenses/translations.html states why
they won't officially approve translated licenses. So a translated
license could be included, but still you would have to accept the
English text and the English one would have to be more prominent and the
unofficial translation clearly marked as such.


Talking about this, would it perhaps be possible to license oficial 
builds differently than source code? Instead of telling the user to 
agree to a source license, we could probably present them with a short, 
understandable and localized EULA.


However, if this is not possible, here's an alternate proposal: how 
about we prepend the license with a localized string that would contain 
short localized summary of the license, and explain in a few words that 
the license itself is in English and that only English text is legally 
binding.


Rimas

P.S. This is most likely more relevant to general list than l10n. 
Somebody care to forward?



--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

Hi Aron,

2010.11.11 08:38, Aron Xu rašė:

I would like to help on coordinating Chinese (China) translation of LO
if it is OK. I am now maintaining GNOME's translation in Chinese
(China) as a committer, but have never contributed to OOo ever before.


Welcome onboard!


As far as I know Chinese translations of OOo is managed by Sun G11n
group, so the community involvement is somehow difficult to take
place. OOo in Chinese (China) uses a quite different translation
style/guideline from other mainstream projects like GNOME/KDE/TP. I
would like to change this situation by revising old translations and
get new translations settled in a same style like other projects
mentioned before.

I would need some help from you on where I can find the translation
files.


You can translate online using Pootle @ 
http://pootle.documentfoundation.org/ or download .po files from there, 
translate offline, and upload them back (or send them to this list, I 
think).
After you register, you'll most probably want me or Andre to give you 
the manager rights on zh_CN.



There is only a wiki page[1] about additional strings we'd
translate for LO, but will we maintain our own version of all
translatable strings? or just these strings from additional LO
features?

[1]http://www.freedesktop.org/wiki/Software/LibreOffice/i18n/


For 3.3, it's these additional features only. After that, the plans are 
to maintain our whole localization independently. So, for 3.3 you should 
probably not change the terminology, but for 3.4, I think you're welcome to.


Note: these are my personal views, and I may be wrong about some 
aspects, in which case I hope someone with authority will correct me. ;)


Regards,
Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 10:37, Aron Xu rašė:

Thanks for your kindly reply, I've registered an account, "happyaron",
please add me as the supervisor of Chinese China translations.


This is now done.

Best regards,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice 3.3 string freeze, Pootle update

2010-11-11 Thread Rimas Kudelis

2010.11.11 11:48, Aidsoid rašė:

We are ready. Where will be the latest pot-file in this evning (or tomorrow
)?


It will be uploaded to Pootle. Just wait for the further announcement 
from Andre.


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 11:24, Aron Xu rašė:

On Thu, Nov 11, 2010 at 16:45, Rimas Kudelis  wrote:

2010.11.11 10:37, Aron Xu rašė:

Thanks for your kindly reply, I've registered an account, "happyaron",
please add me as the supervisor of Chinese China translations.

This is now done.

Best regards,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be
deleted



Thank you very much.

Another question, the file lo-build-zh_CN.po shown on Pootle are not
in sync with freedesktop.org git repository.


Just follow the "LibreOffice 3.3 string freeze, Pootle update" thread. 
Even if it's not in sync now, I suppose it will be tomorrow.


By the way, please add yourself to the wiki page @ 
http://wiki.documentfoundation.org/Language_Teams .


Also note that you don't have to quote full message text (esp. the 
footer) when replying. Just delete everything that's irrelevant to your 
particular reply. ;)


Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 12:46, Rimas Kudelis rašė:
By the way, please add yourself to the wiki page @ 
http://wiki.documentfoundation.org/Language_Teams .




Oops, apparently, there's already a Chinese Simplified team (I just had 
to sort the list alphabetically). Aron, please coordinate your effort 
with Dean Lee .


I wonder why Dean doesn't have a Pootle account, or at least proper 
manager rights there.


Regards,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 13:21, Aron Xu rašė:

Yes there is already a zh-hans item on that page. I'm not sure whether
we'd change it to zh_CN, because in glibc our language code is zh_CN,
and Mozilla use zh-CN. "zh-hans" is the non-official form to express
the combination of zh_CN and zh_SC, similarly "zh-trans" is for zh_TW
and zh_HK.


Dunno where you took that info from. zh-Hans (means Chinese in Han 
script Simplified variant) is an official code from BCP47, which should 
be preferred to zh-CN (Chinese in China).


Similarly, zh-Hant (Chinese in Han script Traditional variant) are 
preferred to zh-TW and zh-HK.


Not all environments are already using these new codes, but in general, 
the direction of movement is towards them, not from them. For example, 
Apple and Microsoft have introduced them in their products recently.


Regardless of said above, I'm quite positive that we should take OS 
expectations into account, and if zh-Han* locale codes aren't recognised 
by Linux, our Linux packages should probably use older, recognised 
locale codes.


Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Libreoffice in Basque (eu)

2010-11-11 Thread Rimas Kudelis

Hi Mikel,

2010.11.11 15:54, Mikel Pascual rašė:

Is there already any basque (eu) team?


Doesn't seem so. At least 
http://wiki.documentfoundation.org/Language_Teams doesn't mention a 
Basque team.


On the other hand, the log of the file says it's been translated by 
Iñaki Larrañaga Murgoitio .



I had a quick look to the strings in the latest libreoffice3.3 po file, and
there is quite a number of typos and grammar errors.
I could review it and get them corrected.


Please do. However, please wait for further announcement. There are 
plans to be update the original strings by tomorrow.



Just in case, I created the MPascual user in pootle.documentfoundation.org
I guess that's everything I'd need to do, right


Please also get in touch with Iñaki Larrañaga Murgoitio and decide which 
one of you (or both?) should be the language manager. Also, please add 
your team to the wiki page. You'll then be granted language manager 
permissions on Pootle.


Best regards,
Rimas Kudelis

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 16:08, Aron Xu rašė:

On Thu, Nov 11, 2010 at 20:50, Rimas Kudelis  wrote:

2010.11.11 13:21, Aron Xu rašė:

Yes there is already a zh-hans item on that page. I'm not sure whether
we'd change it to zh_CN, because in glibc our language code is zh_CN,
and Mozilla use zh-CN. "zh-hans" is the non-official form to express
the combination of zh_CN and zh_SC, similarly "zh-trans" is for zh_TW
and zh_HK.

Dunno where you took that info from. zh-Hans (means Chinese in Han script
Simplified variant) is an official code from BCP47, which should be
preferred to zh-CN (Chinese in China).

Similarly, zh-Hant (Chinese in Han script Traditional variant) are preferred
to zh-TW and zh-HK.

Not all environments are already using these new codes, but in general, the
direction of movement is towards them, not from them. For example, Apple and
Microsoft have introduced them in their products recently.

Regardless of said above, I'm quite positive that we should take OS
expectations into account, and if zh-Han* locale codes aren't recognised by
Linux, our Linux packages should probably use older, recognised locale
codes.

Rimas


I'm not so familiar about BCP 47 but I heard it was designed for
Internet application usage (such as HTML). So I agree to use it in our
wiki and other web documentations.


Well, I haven't read the whole standard either, but I don't think 
Internet is its only application. Similarly, MIME also contains a letter 
for Internet, but it's being used way more widely. ;)



But for the software, I think we are using the ISO 639-1/2 in most
cases. Lists of languages in these two ISO standards are [1] and [2].


ISO 639 defines languages, not locales or scripts. Basically, BCP 47 
combines its codes from those defined in ISO 639, ISO 15924, and ISO 3166.



I think LO is a general desktop application suit and should follow a
standard that is well accepted, there won't be a better choice than
using ISO 639-1/2, which is compatible (or almost compatible) to most
platforms (Windows[3], Mac[4], Linux[5] and other *nix variants).


I don't see zh-CN or zh-TW defined in ISO 639. ;) Code zh is defined, 
but the second part – CN and TW – comes from a totally different 
standard (ISO 3166).

Similarly, Hans and Hant are defined in ISO 15924.

Also, check out [6] for Mac.


BCP 47 is used in OOo (correct me if I'm wrong!), but I don't think
it's a wise choice because we have to first map ISO 639 codes to
BCP-47 for we use gettext have i18n support, then we have to map BCP
47 back to Unix locales (which is almost ISO 639 codes) on most *nix
platforms. Such a process is complicated.


I don't think we're using gettext (yet).


Language code usage of software are in a mess. Chinese on Windows, for
example, we can find:
  * zh_CN (ISO 639-1) for Windows itself (as in [3]);


Well, [3] lists codes for Chinese in different territories, not for 
chinese written in different scripts.



  * zh-Hans (BCP 47) in Vista and .NET 2.0;
  * zh-CHS which should be replaced by zh-Hans but still being widely
used till even today because of Windows XP;


From what I've read, it's going to be obsoleted in future versions of .Net.


  * zho (ISO 639-2) are being used in some Microsoft documents as well.

There is no doubt that we should follow ISO 639-1 because all
standards mentioned above are based on it. For languages that do not
have an ISO 639-1 code, I suggest we use ISO 639-2 so we can easily
use gettext and support *nix systems, and map the codes to respective
platforms (Windows, Mac, etc) if necessary.


That's exactly what BCP 47 does. The "zh" part of zh-Hans is exactly the 
code assigned for Chinese by ISO 639-1. ;)



[1]http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
[2]http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
[3]http://msdn.microsoft.com/en-us/library/ms533052
[4]http://support.apple.com/kb/TA26811?viewlocale=en_US
[5]http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
[6] 
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/LanguageDesignations.html



Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 17:12, Aron Xu rašė:

But keep in mind Hans and Hant cannot cover different kinds of
Chinese, for example there are differences between HK and TW, but they
are combined to one single Hant, which perhaps could not be accepted
by people who are using them, :)


Of course. The question though is if there will ever be two different 
Simplified Chinese localizations of LO. Are those differences really 
noticable?


Quoting the Apple document I linked to before:
The new standard defines new tags for the traditional Chinese (|Hant|) 
and simplified Chinese (|Hans|) scripts. Thus, traditional Chinese 
spoken in any country uses the code |zh-Hant|. Traditional Chinese, as 
it is spoken in Taiwan, now uses the locale code |zh-Hant_TW|. 


IMHO, you can think of zh-Hans as z...@hans in glibc terms. Script is 
simply a different kind of locale modifier than country. Since glibc has 
four Chinese locales, they probably don't need the modifier. But if they 
needed it, the final locale codes would probably look like zh...@hans.



 From what I've read, it's going to be obsoleted in future versions of .Net.

Yes, I've wrote that it is to be replaced, but remember Windows XP is
still running on many people's desktops and laptops, I'm not sure this
situation can change very rapidly in near future.


XP will be EOL'd in 2014 anyway. It won't stay for ever, after all...
Regardless of that, I think our goal is for LO to work as expected in 
your locale. If it does, I don't see the exact language code as a problem.



And some other
applications are still using zh-CHS as a tag on there release
documents to tell people it is in Simplified Chinese, no matter
whether they have to use zh-Hans in new .NET, they just show such
information to end users and people get confused.


Hm, IMO, locale code is a technicality that the end users should not 
care about at all.



Well, I don't mind BCP 47 if it works well, but I've mentioned before
that it cannot cover all different variants, it's just a loosely
defined standard. To be more precise to end users, we might have to
place two sets of translations, zh_TW and zh_HK, into zh-Hant
packages. They are not the same, so we need to do it separately, even
if we make them into a single package to end users.


Not necessary, as stated above. zh...@hant and zh...@hant could be used, 
and then again specifying the country code would probably make the need 
for a script code obsolete...  Ha!:)




Listing language variants with different regions is a good way to
solve conflicts in our development. On the other hand, using a loosely
defined name for our release language pack (which contains everything
fit into the category) is probably good for users.


I think in the end it's about Chinese (Simplified) vs. Chinese (China). 
Until we don't have two country versions of Simplified  or Traditional, 
we can just skip country codes, I think.


Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Pootle admin right request for Chinese (Taiwan)

2010-11-11 Thread Rimas Kudelis

2010.11.11 17:27, Tseng, Cheng-Chia rašė:

Username: zerng07
Languge: Chinese (Taiwan) =>  zh-TW

Thanks in advance.


Granted.

Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 17:35, Rimas Kudelis rašė:

2010.11.11 17:12, Aron Xu rašė:


Well, I don't mind BCP 47 if it works well, but I've mentioned before
that it cannot cover all different variants, it's just a loosely
defined standard. To be more precise to end users, we might have to
place two sets of translations, zh_TW and zh_HK, into zh-Hant
packages. They are not the same, so we need to do it separately, even
if we make them into a single package to end users.


Not necessary, as stated above. zh...@hant and zh...@hant could be 
used, and then again specifying the country code would probably make 
the need for a script code obsolete...  Ha!:)




Listing language variants with different regions is a good way to
solve conflicts in our development. On the other hand, using a loosely
defined name for our release language pack (which contains everything
fit into the category) is probably good for users.


I think in the end it's about Chinese (Simplified) vs. Chinese 
(China). Until we don't have two country versions of Simplified  or 
Traditional, we can just skip country codes, I think.


Interestingly enough, relevant locales I see in Pootle are: zh_CN, 
zh_HK, zh_TW.


Which I guess means that these are the codes that will be used at least 
for 3.3. ;)


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] LibreOffice in Chinese (China)

2010-11-11 Thread Rimas Kudelis

2010.11.11 17:47, Aron Xu rašė:

On Thu, Nov 11, 2010 at 23:40, Rimas Kudelis  wrote:

Interestingly enough, relevant locales I see in Pootle are: zh_CN, zh_HK,
zh_TW.

Which I guess means that these are the codes that will be used at least for
3.3. ;)


Well, zh_CN and zh_SG shoul fall in Hans's category, but I've never
seen any people translating software to zh_SG, they just use zh_CN
directly.


Which is exactly why zh_Hans is more correct. ;)


zh_HK and zh_TW fall in Hant's category, which should have a solution.
If we define it like zh...@hant, the modifier @hant can be omitted,
because there is nothing else could make people puzzled if the
modifier does not present. (In fact @hant could be used to help put
correct files into correct language pack, :D )


I didn't say there *has* to be only one Chinese Traditional language 
pack. ;) It would make sense to have a "general" Hant language pack if 
we only had one localization, but if we have two, we can have two 
language packs too.


I suggest we stop this discussion here, or go off-list in order not to 
bother people too much... ;)


Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Re: LibreOffice 3.3 string freeze, Pootle update

2010-11-12 Thread Rimas Kudelis

Hi all,

2010.11.12 11:33, Petr Mladek rašė:

I have just pushed the updated lo-build.pot and synced .po files in the
git repo. Please, take them.

André, could you please sync pootle once again?


I'm trying to do that now. Please do not work on those files for now.

Also, I'll try to merge those files with those we had during testing. 
Hope there are no objections?


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Re: LibreOffice 3.3 string freeze, Pootle update

2010-11-12 Thread Rimas Kudelis

2010.11.12 14:21, Rimas Kudelis rašė:

Hi all,

2010.11.12 11:33, Petr Mladek rašė:

I have just pushed the updated lo-build.pot and synced .po files in the
git repo. Please, take them.

André, could you please sync pootle once again?


I'm trying to do that now. Please do not work on those files for now.

Also, I'll try to merge those files with those we had during testing. 
Hope there are no objections?


OK, it took me a rediculously long amount of time, but I think I finally 
managed to trick Pootle into doing what it should. All files have been 
updated from git, and then merged with what we already had in the 
libo33_test project. Feel free to continue working on libo33 project, 
and report any problems you may find.


As a precaution, I don't suggest using the Update from templates 
function, because it seems to misbehave sometimes. Misbehaviour of that 
function is exactly what took me so long. Also note that the 
calculations on the project page are a bit off. The actual number of 
strings/words is 377/1877.


Happy localizing!
Rimas Kudelis

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Re: LibreOffice 3.3 string freeze, Pootle update

2010-11-12 Thread Rimas Kudelis

2010.11.12 18:46, Cor Nouws rašė:

Hi Sophie,

Sophie Gautier wrote (12-11-10 17:36)


You need to ask for the rights to the NL language admin on Pootle.


Hmm, didn't I do that already ?
Can you do that, or André?

Thanks,

Cor
 (In need for a personal secretary ;-) )



You do have rights already.

What do you mean by "it is not saved"? Do you see (and use!) the Submit 
button in the UI?


Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Bosnian language translation

2010-11-14 Thread Rimas Kudelis

Hi Vedran,

2010.11.14 19:20, Vedran Ljubović rašė:

I would like to coordinate translation of LibreOffice into Bosnian
language. As you may note I was previously (a long time ago)
translator for OpenOffice.org. I would also like to request admin
rights on Pootle for Bosnian

login: vljubovic


I gave you Bosnian language manager rights on Pootle.


Can someone please brief me, what is the contents of lo-build-*.po
file? It is much smaller than complete GUI translation for OOo so
there is probably something else that needs updating too.


It contains the additional strings that aren't part of OOo (a diff, if 
you like). This will be changed post 3.3 though.


Best regards,
Rimas Kudelis

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Bosnian language translation

2010-11-14 Thread Rimas Kudelis

Hi Vedran,

please also add yourself to the wiki page: 
http://wiki.documentfoundation.org/Language_Teams


Thanks!

Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



[libreoffice-l10n] Re: [libreoffice-website] l10n on LibO and Drupal Website integration

2010-11-18 Thread Rimas Kudelis

Hi Carlos,

2010.11.18 11:40, Carlos Jenkins rašė:

As I stated before, I want to configure a Drupal prototype with Localization
server module for Drupal, that is the one that empowers
http://localize.drupal.org/, as a possible LibreOffice translation tool
totally integrated with the Drupal website (user base, login, roles, etc).

I'm still a little occupied working on a graphic design proposal for the
website with the other members of the Drupal development team (will be ready
soon!), but when over I really want to get into this. I was a little lost
some week ago trying to figure out how to translate LibO, I thought I needed
to hook the /build/po/.po with the translation UI. But, finally, with
the today announce of LibO 3.3 beta 3 I found out this documentation:
http://www.freedesktop.org/wiki/Software/LibreOffice/i18n/translating_3.3

:D
Now, I do have a more general idea. So, the purpose of this e-mail is to
know if there is someone on this mailing list that know If I'm on the right
way.

Assumptions:

1. As stated on the previous documentation link, there is a Git hook that
merges the lo-build.pot (if that file has changed) with all the .po files on
each commit. I'm right?

So, what we need to do is:

1. Copy all the current lo-build-.po from the repository to a folder
where webserver has write access (for example
/var/www/community-translations/)
2. Hook the Drupal UI to those .po files.
3. Configure a cron job that do a checkout of the git repository, merges all
the repository lo-build-.po files (which has the added strings after
each commit thanks to the git hook) with those translated during that day by
the community (again, in, for example, /var/www/community-translations/) and
then do a commit of the resultant lo-build-.po with a commit message
like "Synchronization with the translated strings from the Localization
server"

Opinions, corrections, threats (jejeje)?


I think this subject is pretty much on the border between website and 
l10n mailing lists. You may want to keep l10n informed too,


Also, the information on the wiki page is likely to change post 3.3. 
AFAIK, the plan is to begin hosting (and working on) full localization 
ourselfes after the release, instead of having just the diff.


Also, I'm not sure if you know, but we already have a web-based L10n 
interface at http://translations.documentfoundation.org/. I wonder if 
you could perhaps make some formal comparison of Pootle and the Drupal 
Localization module, and point out which one and why is better in your 
opinion.


Regards,
Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Kazakh translation

2010-11-19 Thread Rimas Kudelis

Hi Baurzhan

2010.11.19 11:20, Baurzhan Muftakhidinov rašė:

There was Kazakh translation for OpenOffice 2.3 prior to 3.0
Unfortunately, it wasn't maintained.

There is no Kazakh PO file in main git branch
(http://cgit.freedesktop.org/libreoffice/build/tree/po),
but there is Kazakh Language Pack in downloads for LibreOffice 3.3beta3.

http://download.documentfoundation.org/libreoffice/testing/3.3.0-beta3/rpm/x86/

So, is there Kazakh PO file, which I can pick up and work on it?


you have two choices now:
1) download 
http://cgit.freedesktop.org/libreoffice/build/tree/po/lo-build.pot, 
rename it to lo-build-kk.po, work on it offline, and send it here later.
2) if you want to work online, feel free to register on 
http://translations.documentfoundation.org/ and work there. I've 
initialized the file for your language. If you choose this option, 
please also drop a note here to obtain the language manager rights for 
Kazakh.


Also, if you plan to keep on contributing to LibreOffice in future, 
please add yourself to the Language teams list on Wiki: 
http://wiki.documentfoundation.org/Language_Teams .


And finally, feel free to ask any further questions here.

Best regards,
Rimas Kudelis

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Update on FR localization and terminology

2010-11-20 Thread Rimas Kudelis

Hi Sophie,

2010.11.19 16:06, Sophie Gautier rašė:
I've updated the French localization on Pootle and I'm not sure if I 
must ask for the file to be committed here, or if it will be done on a 
more automated way for all Pootle languages before 3.3 final.


I'm not sure what exactly the plan is. In any case, I don't think it 
hurts the process to ask explicitly for the file to be committed. Lior?


I've also extracted the FR glossary file from SunGloss and transformed 
it in a .po file that is ready to be the terminology file on Pootle. 
Could one of the Pootle Admin upload it instead of the Gnome one 
currently uploaded? Both files (last l10n and terminology) are here :

http://sophiegautier.com/l10n/


I've uploaded as libreoffice/fr.po, and left the gnome file intact. Do 
you really want me to delete it?


Also, may be this terminology.po file could serve as a basis for the 
other languages who has no terminology currently because it contains 
all the UI strings in English. It should be possible to remove the 
French strings and update it with a TM, then upload it on Pootle to be 
completed?


It is possible, but I'm not really sure if there's a demand for this nor 
if this is the best approach. Your file has more than 14K strings, of 
which some are dupes (e.g. "rounded rectangle" and "rounded 
rectangle\t") or look a bit out of place in terminology (e.g. the very 
first string: "%PRODUCTNAME %PRODUCTVERSION [doc_type]"). I doubt every 
team would have enough resources and/or determination to translate them 
all (note: I don't mean to depreciate your work, treat them as simply 
observations from a fellow localizer).


By the way, Pootle also has internal means of generating terminology, 
which could probably work at least for some languages. I just tried this 
for Lithuanian on the sandbox installation of Pootle, and sadly it left 
quite a bunch of terms untranslated (I guess Pootle got confused with 
different grammatical cases of the same term), but we may experiment 
with it a bit more later. Also, I hope that maybe it would work better 
when we have all of OOo translation files in Pootle, not just our 
additional strings.


Best regards,

Rimas

--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Pootle dowload files glitch?

2010-11-20 Thread Rimas Kudelis

2010.11.20 11:52, Olivier Hallot rašė:

Hi pootle admins

I tried to download lo-build-pt_BR.po in order to work offline, but 
pootle complains that /var/www/Pootle/po/libo33/lo-build-pt_BR.po does 
not exist, although I can translate it on-line.


A glitch in the configs?

The link was invoked in the page (with admin rights)
http://translations.documentfoundation.org/pt_BR/libo33/edit.html

Thanks


Hi Olivier,

the file indeed did not exist, and I think it's because of the problem 
we had with that file being also assigned to Breton language, which 
caused me to delete it and then restore it, and I guess I did not 
restore it fully...


I think I did it now though, and it should work.

Regards,
Rimas


--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] Pootle dowload files glitch?

2010-11-20 Thread Rimas Kudelis

2010.11.20 17:09, Freek de Kruijf rašė:

I tried to download lo-build-nl.po from
http://translations.documentfoundation.org/nl/libo33/edit.html

however, I got a truncated? file with 377 messages instead of the mentioned
1480 messages.


No, you're just confused by numbers a bit. :)

In your file, 1480 WORDS need attention. Total count of MESSAGES is 377 
in all languages.


Rimas




--
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted



Re: [libreoffice-l10n] About occitan-lengadocian's translation

2010-11-26 Thread Rimas Kudelis

2010.11.26 19:38, bruno gallart rašė:

Bruno GALLART
Occitan lengadocian's project for LibreOffice

Hi all,

One person should do the manipulation to introduce occitan's 
translation in Libreoffice.org but he did nothing. I want give the 
priority for LibreOffice and I should like introduce the occitan's 
translations in LibreOffice.org but  there are many "but" I don't 
really understand this explanation here 
http://www.freedesktop.org/wiki/Software/LibreOffice/i18n/translating_3.3.


I took the file openoffice_org-oc and I don't understand what I must 
to do ,


There is no one explanation in french, little and clear because I am 
not an specialist of the pot's files or po's files ?


Sorry to be a newbee in manipulations of translation 'files,

Cheers,
Bruno






--
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***



Re: [libreoffice-l10n] About occitan-lengadocian's translation

2010-11-26 Thread Rimas Kudelis

Hi Bruno, *,

first of all, sorry for my previous email which is a mistake (I pressed 
a wrong keyboard shortcut). Just ignore it.


2010.11.26 19:38, bruno gallart rašė:

Bruno GALLART
Occitan lengadocian's project for LibreOffice

Hi all,

One person should do the manipulation to introduce occitan's 
translation in Libreoffice.org but he did nothing. I want give the 
priority for LibreOffice and I should like introduce the occitan's 
translations in LibreOffice.org but  there are many "but" I don't 
really understand this explanation here 
http://www.freedesktop.org/wiki/Software/LibreOffice/i18n/translating_3.3.


I took the file openoffice_org-oc and I don't understand what I must 
to do ,


There is no one explanation in french, little and clear because I am 
not an specialist of the pot's files or po's files ?


Sorry to be a newbee in manipulations of translation 'files,


Bruno, first of all, keep in mind that for 3.3 we're reusing the strings 
from OpenOffice.org, and only translating those that don't exist in OOo 
ourselves. If Occitan localization of OpenOffice.org is in a bad shape, 
translating just those additional strings won't help much.


Having said that, here are your options for localizing LibreOffice files:

If you want, you can translate online. Just create yourself an account 
at our online translation system [1], and ask me (by writing to the 
list) to add Occitan to the list of available languages. Also tell me 
your user name so I can grant you the necessary language manager 
permissions.


If you want to translate offline, here's what you can do:
1) download the translation template file [2]
2) rename it to lo-build-oc.po
3) use a .po editor to translate the contents of that file. There are 
quite a few .po editors to choose from. My personal favorite is Virtaal 
[3], but you may also want to try poEdit [4], or something else.
4) upload the file and send a link to it to this list, or just send it 
here as an attachment (don't forget to compress it first).

5) enjoy the fruit of your work

[1] http://translations.documentfoundation.org
[2] 
http://cgit.freedesktop.org/libreoffice/build/plain/po/lo-build.pot?h=libreoffice-3-3

[3] http://translate.sourceforge.net/wiki/virtaal/index
[4] http://www.poedit.net/

Best regards! Hope this email is helpful.
Rimas Kudelis

--
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***



Re: [libreoffice-l10n] About occitan-lengadocian's translation

2010-11-26 Thread Rimas Kudelis

Hi Bruno,

2010.11.26 22:58, bruno gallart rašė:
I have created my compte with the name bruno. Can you  add occitan 
project for LibreOffice ?


Yes, and you have the language admin rights now. Go translate!

It will be possible do create a project occitan-lengadocian because 
occitan alone it is a grop of languages and no one langage ? Thera are 
occitan-gascon, occitan-provencal etc... If no, it is not a problem.


It should be possible, if you give me the language codes and names. 
However, I suppose a generic Occitan could also exist, no?


Rimas




--
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***



Re: [libreoffice-l10n] About occitan-lengadocian's translation

2010-11-26 Thread Rimas Kudelis

2010.11.26 23:28, Rimas Kudelis rašė:

Hi Bruno,

2010.11.26 22:58, bruno gallart rašė:
I have created my compte with the name bruno. Can you  add occitan 
project for LibreOffice ?


Yes, and you have the language admin rights now. Go translate!


Please also list yourself on the wiki: 
http://wiki.documentfoundation.org/Language_Teams
and add/fill in an Occitan row at 
http://wiki.documentfoundation.org/Translation_for_3_3


Rimas


--
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***



Re: [libreoffice-l10n] localization bug

2010-11-26 Thread Rimas Kudelis

Hi all,

sorry for the delay. I've just updated the Pootle files from git. 
Hopefully this didn't drop any existing translations, but in case it 
did, please raise your hand.


This update added one string (My AutoText) to the localization files, 
which means all translations are now incomplete again.


Regards,
Rimas


2010.11.20 01:20, Andras Timar rašė:

2010.11.14. 22:13 keltezéssel, Andras Timar írta:

Conclusion: localized mytext.bau files (currently hu and sl) can be
removed from the source, because they are useless. Don't send more
translations via bugzilla. We need to localize this string elsewhere.
I guess we can "intercept" this string in
sw/source/ui/misc/glossary.cxx and replace it to the localized
equivalent (a new "My AutoText" string should be added to
glossary.hrc/src in order we can localize it normally). I don't have
the patch but I'll work on it.

The patch has been pushed to libreoffice-3-3 branch, I updated the pot
file and all po files (hu, lt, sh, sl, and sr already have translations
for "My AutoText"). Please update the files in Pootle.

Thanks,
Andras




--
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***



  1   2   3   4   5   6   >