Re: Report-Msgid-Bugs-To in the .po files

[Ask Hjorth Larsen via gnome-i18n]

El mar., 2 ago. 2022 11:03, Milan Crha via gnome-i18n 
escribió:

> Hello,
> this is rather a question, than a request. I noticed that the
> GNOME/evolution project's .po files contain Report-Msgid-Bugs-To with
> various values, often referencing the project itself, like this:
>
>Report-Msgid-Bugs-To: https://gitlab.gnome.org/GNOME/evolution/issues
>
> While it makes sense, the translations are not dealt with in the
> project, but in the
>
>https://gitlab.gnome.org/groups/Teams/Translation/xy
>
> instead, thus any reported issues are forwarded to the related
> translation team. Would it make sense to change the
> Report-Msgid-Bugs-To to the correct translation team URL?
>


The "Report-Msgid-Bugs-To" is for reporting bugs in the "msgid", meaning
the English string. As such, it will need to go to the developers. For
actual translation bugs there's the team and last-translator emails.

Best regards
Ask


> Though more importantly, can the users get to the URL anyhow easily? If
> the users cannot get to it, then it doesn't make much sense to change
> the Report-Msgid-Bugs-To, because they would file a bug against the
> project itself, which will be copied to the Translation team
> afterwards.
>
> This may affect more projects, the GNOME/evolution is only a project I
> noticed this with.
>
> Bye,
> Milan
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Issue sending translations for Contact

[Ask Hjorth Larsen via gnome-i18n]

Dear Quentin,

El lun., 20 jun. 2022 10:13, Niels De Graef via gnome-i18n <
gnome-i18n@gnome.org> escribió:

> Hi Quentin,
>
> I'm afraid I'm not really knowledgeable on translations. However, I'll
> add the GNOME i18n list to the conversation, and hopefully they can
> help you out :-)
>
> Cheers,
> Niels
>
> On Sun, Jun 19, 2022 at 8:43 PM Quentin PAGÈS  wrote:
> >
> > Hello Niels,
> >
> > I am a translator for the Occitan language.
> > I am experimenting issue when sending my work via the web site.
> > It says something about the «msgfmt -vc» check that fails...
> > It's here: https://l10n.gnome.org/vertimus/221294/43/
> > I am absolutely clueless about how to fix this...
> > Would you know what happen?
>

The message appears because there is a syntax error in the file. If you
read the error message closely, it should be enough to see what is wrong
and fix it it. Else you can show the file and error message to someone else
who might know.

Best regards
Ask





>
> > Regards
> >
> > --
> > Quentin PAGÈS
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: [libadwaita] Stable branch is not on DL

[Ask Hjorth Larsen via gnome-i18n]

Hi,

Am Mo., 7. Feb. 2022 um 12:21 Uhr schrieb Piotr Drąg via gnome-i18n
:
>
> pon., 7 lut 2022 o 11:29 Alexander Mikhaylenko via gnome-i18n
>  napisał(a):
> >
> > Looks like there wasn't an automatic notification, I branched
> > `libadwaita-1-0` some time ago:
> >
> > https://gitlab.gnome.org/GNOME/libadwaita/-/commits/libadwaita-1-0/
>
> Hi,
>
> Automatic notifications only work for “gnome-x” branches. Thanks for
> letting us know, I updated Damned Lies.

Thanks, Piotr!  I recall that Secrets just had a 6.0 release, but
noticed its stable branch on D-L is still release/5.x .  Should this
also be updated?

Release links:
https://gitlab.gnome.org/World/secrets/-/tree/6-1
https://gitlab.gnome.org/World/secrets/-/tags/6.1

(The release branches are not consistently named)

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Shortcuts in DL workflow

[Ask Hjorth Larsen via gnome-i18n]

Dear Claude,

Am So., 7. Nov. 2021 um 10:41 Uhr schrieb Claude Paroz :
>
> Dear translators,
>
> Following the issue opened by Yaron [1] about DL, I'd like to suggest
> some modifications to the traditional Web translation workflow:
>
> - Allow to submit a translation or a review directly without passing
> through the reserve step. The reserve step still remains, of course, but
> would be optional.
>
> - Allow a committer to Submit to repository as soon as a .po file is
> available in the workflow, without requiring a review or a Ready for
> submit action.
>
> This would shorten the minimal number of required form submits to 2
> (upload the translation / submit to repository).
>
> What do you think about this. I have the feeling that it would be an
> answer to a concern that several coordinators have expressed in the
> past, especially for smaller teams.

Thanks a lot for considering this -- it would be absolutely fantastic.

FWIW I have two main usecases:

 * A current limitation of D-L is that it's not possible to have
inline discussions of changes.   Compare to Gitlab merge requests
where any line can be commented and have a full discussion thread.
In order to have inline discussions one needs to use another tool for
the proofreading part of the workflow, and hence most of the clicking
in D-L is unnecessary.
 * Normally 90% of changes happen in 10% of modules.  The other 90% of
modules have very few changes and it makes sense to proofread them in
a single batch after translating those modules with many changes.  But
manually committing every small change is a lot of clicking.

(I also dream of having a commit-multiple-files option.  It could
preview the change in translation stats so it's easy to verify that
each file is committed to the right module.)

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Status of Danish translation team and open merge request against Orca

[Ask Hjorth Larsen via gnome-i18n]

Dear Joanmarie,

Am Di., 6. Juli 2021 um 18:01 Uhr schrieb Joanmarie Diggs :
>
> Hey Translation Team.
>
> Could someone please take a look at this Danish translation merge
> request a translator submitted for Orca [1], and perhaps also help the
> submitter coordinate with the right team members going forward?
>
> Thanks in advance!
> --joanie
>
> [1] https://gitlab.gnome.org/GNOME/orca/-/merge_requests/114

Thanks, we'll be in contact.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Finding strings in GNOME

[Ask Hjorth Larsen via gnome-i18n]

Am Mo., 10. Mai 2021 um 02:17 Uhr schrieb scootergrisen via gnome-i18n
:
>
> Den 09-05-2021 kl. 23:21 skrev Daniel Șerbănescu:
> > În data de Du, 09-05-2021 la 22:37 +0200, Matej Urban via gnome-i18n a
> > scris:
> >> Hello, I need a bit of help.
> >> I frequently see strange translations, but then can not find, which
> >> packet those belong to. Is there a simple way to find them?
> >
> > Hello Matej,
> > Here are the steps I usually do:
> > 1. On your language team page in Damned Lies open a release page (Like
> > Gnome 40). There is a link to download all the .po files, it is located
> > at the bottom of translation statistics. So click that link to download
> > E.g. For the Romanian team the link would be at the bottom os this page:
> > https://l10n.gnome.org/languages/ro/gnome-40/ui/
> > 
> > 2. Extract the .po files in a folder
> > 3. Open a terminal in that folder
> > 4. Use the following grep command: grep -ri "the string you are looking
> > for" *
> > (replace "the string you are looking for" with the actual search term.)
> >
> > Be aware that there can be memonics in the original string so you could
> > try searching for a part of that string.
>
> Do anyone know how to ignore these "_" memonics that might be in strings?
>
> So i can search for "Test" and i will find all these:
> "Test"
> "_Test"
> "T_est"
> "Te_st"
> "Tes_t"

With pyg3t [1] you can do:

gtgrep --accel=_ Test filename.po

It ignores the accelerator character when matching and also prints the
whole msgid+msgstr+comments rather than just the matching line.

For checking files in many directories, one would use find and xargs.  E.g.:

find -name "*.po" | xargs gtgrep --accel=_ Test

[1] https://gitlab.com/pyg3t/pyg3t

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Danish team have long waiting periode for review

[Ask Hjorth Larsen via gnome-i18n]

Dear scootergrisen, and all,

Since I'm the coordinator for Danish, I feel that I need to post a response.

Am So., 18. Apr. 2021 um 19:58 Uhr schrieb scootergrisen via
gnome-i18n :
>
> It's a long one...
>
> Hi i have been translating GNOME modules to danish
> (https://l10n.gnome.org/teams/da/) for some time.
>
> But since i have spent so much time translating so many modules/strings
> for a long time there have been a problem.
>
> The problem is that the time it takes for the translations to get into
> the software is way to long.
>
> Currently the translations that have waited the longest was submitted
> for review on the danish mailing list january 10. 2020. So that's 1 year
> and 3 months i have waited so far just to get someone to review the
> translation.
>
> It have been like this for a years now and i have mentioned it many
> times on the danish mailing list for a long time.
>
> It seems the danish team have a rule that all translations should be
> reviewed by another person before it can get into the software.
>
> That may sound like a good idea at first but when someone like me
> translates a lot of modules and nobody wants to take the time to do the
> reviweing i don't think this is a good idea anymore.

It is unfortunately difficult to motivate others (and myself) to
proofread certain translations for reasons that we have discussed
within the team and are, as far as I know, not interesting for
subscribers of the i18n list.  You could be more proactive in
proofreading other translators' submissions.  And I encourage more
communication, so the team agrees on the kinds of changes that we
make.  Even if the team is just three people.

>
> Instead i think it would be better to include the translations i have
> made in the software if nobody wants to review within a periode og time.
> Let's say nobody shows interest in reviewing the translation for 1 or 3
> months or something like that.
> Then at a later time when/if people want to review the translations they
> can do so at any time they wish.
>
> If the translation is slowed down for 1 year just to find a few spelling
> mistakes and fix commas i don't think this is worth it. This could
> easily be fix at any later time allowed the translator to keep going
> insted of being slowed down and perhaps loosing interst in continuing
> the work.

Well, I think it is better that translators learn up front, instead of
producing a large quantity of translations with the same problems
repeated.  This is not limited to commas.

>
> For danish translation in other projects (not GNOME) it is totally
> standard way that the translations is just approved without review
> because there is just about nobody interested it taking the time to
> review. But nothing prevents them doing so at a later time.
>
> Anyway my suggest is that i can have the waiting translations included
> in the software without having to wait for review by the danish team.
> That way i can better move on with the translation work.
> And should the time come when the danish team have found the time to
> review the translation nothing is preventing them in doing so.
> I can keep a list of the translation which is missing review.

Not having proofreading will mean that every translator uses a
different style.  Having proofreading means that translators will know
each others' styles, learn from each other, and can hopefully agree on
some things.  Allowing fast-track submissions of translations does not
promote this sharing.

>
> The danish team don't use damned-lies to review and upload translations
> just to reserve modules for translation.
> Danish team use a mailing list for the files.
> And since there is no public archive of the mailing list i can't give a
> link to show people what i have submitted and when.
> So it's not easy to keep track of it all.

Some things are definitely broken.  I wish someone had time to fix them.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Glom example files

[Ask Hjorth Larsen via gnome-i18n]

Hi,

Consider for example
https://l10n.gnome.org/vertimus/glom/master/example_music_collection/da/

These are "glom examples".  I can download the translation templates
from D-L but I cannot commit them.  There is no option to commit in
the D-L interface like for other po-files.

I could commit them to git manually but they look wonky -- in existing
files, authors are listed as:

"Last-Translator: Someone \n"
"Language-Team:  \n"

...which tells me that they're not the product of a normal workflow.

There's a readme (glom/examples/po_files/README) telling me about
import/exporting those files by running make.  Is that my job --
commit things that are not po files?  Or do I commit the po-files and
someone else does the rest as part of some process?  Is there a way to
know these things?

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: String freeze break for gnome-software to add context

[Ask Hjorth Larsen via gnome-i18n]

OK, approval 2/2.

Best regards
Ask

Am Fr., 5. März 2021 um 13:48 Uhr schrieb Daniel Mustieles García via
gnome-i18n :
>
> I agree with you so we should wait for the second approval for this request.
>
> Regards
>
> El vie, 5 mar 2021 a las 13:31, Alexandre Franke () 
> escribió:
>>
>> On Fri, Mar 5, 2021 at 1:18 PM Daniel Mustieles García via gnome-i18n 
>>  wrote:
>>>
>>> Sorry, I missed this email...
>>>
>>> Here is the 1/2 fron i18n.
>>>
>>> I believe Alexandre will give you the second vote, but let's wait his 
>>> response ;-)
>>
>>
>> As the reporter I’m obviously biased towards approving it… which is exactly 
>> why I didn’t respond. We have a pool of coordinators, it would be better if 
>> I wasn’t one of the two approvals, seeing as I’m basically the requester.
>>
>> --
>> Alexandre Franke
>> GNOME Hacker
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Ask Hjorth Larsen via gnome-i18n]

Dear Fòram, and all,

Am Mo., 22. Juni 2020 um 16:39 Uhr schrieb Fòram na Gàidhlig
:
> IMO the optimum workflow would be to pull weblate translations with a
> scheduled GitLab CI job and let the CI commit them into a branch when
> they're green. The master branch should be protected and nobody should
> be allowed to push there directly. Even skilled and experienced project
> maintainers will make mistakes, because nobody is perfect.

What about this similar model:

 * We (translators) always commit to a fork of the central repo.  D-L
runs on top of this fork rather than the projects directly.
Committers/coordinators have push access to all those forks.
 * Projects merge from this fork in some manner which is controlled by
maintainers -- subject to CI pipelines etc.

I suggest this because it might solve the most important immediate
problems while it looks (to me) as a relatively small step.
Introducing weblate could be an additional step.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: GTXML report: errors in documentation

[Ask Hjorth Larsen via gnome-i18n]

Thanks Daniel.

For future reference, it might be helpful to include also the project
directory.  This is because gimp-help-2 has files like "glossary.po"
which are not sufficient to tell where the file comes from.

Best regards
Ask

Am Di., 3. Sept. 2019 um 12:12 Uhr schrieb Daniel Mustieles García via
gnome-i18n :
>
> Hi all,
>
> As usual, I've created a report (attatched) with the languages containing 
> typos or errors in tags in documentation files. Here is the list of the 
> affected languages:
>
> ca
> cs
> da
> es
> fr
> ja
> pt_BR
> ro
> ru
>
> Please fix them before the new release, to avoid errors when compiling the 
> affected modules. If you need help fixing it, just let me know and I'll help 
> you.
>
> Regards
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Dear all,

Am Fr., 26. Apr. 2019 um 10:43 Uhr schrieb Mathieu Bridon
:
>
> On Fri, 2019-04-26 at 10:38 +0200, Niels De Graef via desktop-devel-
> list wrote:
> > Note that you don't need to script this kind of stuff, if you use the
> > following tricks:
> >
> > # 1. This creates a symbolic link from master to mainline, which
> > solves your problem already.
> > $ git symbolic-ref refs/heads/master refs/heads/mainline

Unfortunately that is not sufficient to solve the problem.  The
problem was not how to update the default branch for one repository.
I have 250+ repositories checked out of GNOME.  Now maintainers start
renaming branches for no justified reason (moving to git was well
justified and everyone did so; moving to Gitlab likewise) so where
before it was always master, now it will be anyone's guess.  This is a
slippery slope.  Rule number one is keep it simple.

> >
> > # 2. This worfklow doesn't even need you to specify a branch if you
> > start from mainline/master
> > $ git checkout -b feature/
> > # work, work, work and commit
> > # If you no longer want to continue on this branch, you can go back
> > to the previous one with
> > $ git checkout -

So we need to change workflow for all of GNOME because one maintainer
decides that we must use a special name for one project.  That does
not sound like a good decision. The maintainers should keep in mind
that there are people whose work touches all the repositories, and
uniformity is a requirement for an efficient workflow.  If I only
needed to ever work on a single repository or a few repositories, I
would not care either.  So that is what the maintainer probably
thinks, but surprisingly, the devs don't belong to the set people whom
the change affects the most.

Typically we are interested in committing either to master, or to a
stable branch like gnome-3-32 and then also master (but now we need an
extra incantation to see the name of the branch), but for hundreds of
projects.  The appropriate branch names can often but not always be
inferred from the filename.  Often we have simultaneous changes across
large numbers of modules, like when GNOME started recommending unicode
punctuation (“” »« etc.).

>
> # 3. Tab completion works wonders:
> $ git checkout ma
>
> Mike said himself that choosing a new name starting with the same
> letters as "master" was a deliberate choice to further minimize the
> disruption.

I always use tab completion when working with git.

Both Damned-Lies and our own scripts/workflows rely on the fact that
there are certain common elements shared by the GNOME projects: Things
like everything being on GNOME's Gitlab instead of svn, consistent
naming of files and paths (po/.po, LINGUAS), and so on.  For any
particular change, we *can* deal with it, at the cost of needing to
invest more time, and making mistakes at a higher frequency because
that is what you get when things are not as simple as possible.

There are always a few repositories that don't work well, sometimes
D-L produces inconsistent filenames or something was moved to a
different Gitlab group, you need manually commit the documentation
within a certain class of project, and so on.  We can always deal with
these exceptions which are generally unintended or at least not the
product of willful deviation from the standard, but we don't /like/ to
do those things, and there is no reason why our scripts and
infrastructure should be made more complicated to satisfy everyone's
whims.

This is not even a UI change.  Years ago there was a discussion for
changing GNOME branding because the logo (a foot) is considered rude
in some cultures.  As I recall, such a change was not made.  Now we
compromise the simplicity of our infrastructure to satisfy political
standards that do not even affect users.

Please go back to master.

Best regards
Ask

>
>
> --
> Mathieu
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Am Mi., 24. Apr. 2019 um 13:57 Uhr schrieb Michael Gratton :
>
> On Wed, Apr 24, 2019 at 13:31, Daniel Mustieles García
>  wrote:
> > So hardcoding the name "mainline" to the list of branches that Damned
> > Lies' looks up resolves the problem for you... and tomorrow another
> > maintainer decides to rename it's master branch to
> > whatever_non_offensive_name and DL breaks again until a patch is
> > submited... no, sorry but this is not a solution for this.
>
> I agree, which is why I have been working to fix it places where it's
> hard coded.

When actually working on the project, you probably type the branch
name now and then.  This means you need to be aware of it - it is a
piece of information which must reside within your short-term memory.
This is not a problem if you work on one project.  It is a problem if
you work on hundreds of projects.  Then you need to run things like
git branch and git status, read the output, and decide what to type
based on that.  A good workflow seeks to minimize the risk that humans
make mistakes, and that means making things as simple as possible.
Please do not remove this particular piece of simplicity from our
lives.

I can also script my way out of this for most of the tasks I need to
do.  But inconsistencies have never made life easier in computing, and
this is an inconsistency which we could simply choose not to deal
with.

Best regards
Ask

>
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Dear Michael,

Am Mi., 24. Apr. 2019 um 13:17 Uhr schrieb Michael Gratton :
>
> Hi Daniel,
>
> On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n
>  wrote:
> > Great, but having modules with no standard name for
> > master/trunk/whatever branch might break applications like Damned
> > Lies, so this rename should be reconsidered, at least until we decide
> > to rename the whole modulesed's master branch to another one.
>
> The name of the mainline branch in git cannot be assumed to be "master"
> since git allows it to be changed, and as of Git 1.8 the server sends
> and the client looks for the name of the mainline branch when the repo
> is being fetched (e.g. via a clone). Changing the name of the mainline
> branch is easy to do, and in fact our Gitlab instance lets anyone with
> appropriate privs for a project do just that from the project settings
> UI.
>
> So, Damned-Lies' current behaviour is broken because it makes the
> assumption that the mainline branch is always named "master" (after
> trying a few other hard-coded names), and so it breaks in situations
> like this. However, I submitted a workaround that adds "mainline" to
> that list, and that MR[0] has been merged. I'm not sure if it has been
> deployed, but I think it may have been about a week ago.
>
> Of course, this should be fixed properly to just ask the repo what the
> right name is, and if there's interest in fixing it properly I'll
> happily look into it and submit another MR. I've also worked with
> Andrea to fix places in the sysadmin code (git hooks, GitLab
> integration, etc) making the same assumption[1], and that's been
> working fine for weeks.
>
> Anyway, it should be fixed for Geary now, so if you're still having
> problems with this as of this time last week, please let me know so I
> can look into a fix.
>
> > What would happen if every module maintainer decides to rename it's
> > master branch? It will be a mess... I just think we should keep names
> > homogeously, don't mind if it's called master, trunk... ;-)
> >>
>
> No, everything will work fine as long as people stop writing code that
> (wrongly) assumes git's mainline branch is necessarily called "master".
> :)

Using different branch names in different GNOME projects is not a
problem for git, which is a computer program, but it is a problem for
humans who need to agree how to do their everyday work.  Spaghetti
code may also happen work and is hence totally valid (or so says the
computer), but most developers reject unreadable code because it is
makes everyday work more difficult and causes more errors to be made
by the humans who work with it.

In this case, we need to work with a lot of different repos and
branches.  There are good technical reasons to make some essential
changes like migrating from svn to git, or moving to Gitlab, but this
change does not give us any technical advantage, it only makes things
less consistent and more time consuming than before.

Best regards
Ask

>
> //Mike
>
>
> [0] -
> 
> [1] -
> 
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Dear all,

Having a master branch does not imply slavery anymore than chess
master, masterpiece, jedi master, or master of science in engineering,
but not having a master branch, and particularly having inconsistent
branch names, means extra real work for real people, and particularly
those who work with branches of multiple projects.  Please do
reconsider this change.

If we must change, and if they change the default name in git, could
we at least wait some years until everything is figured out and
reaches stable OS packages?

Best regards
Ask

Am Mi., 24. Apr. 2019 um 12:01 Uhr schrieb Daniel Mustieles García via
gnome-i18n :
>
>
>
> El mié., 24 abr. 2019 a las 11:25, Carmen Bianca Bakker 
> () escribió:
>>
>> Je mer, 2019-04-24 je 10:32 +0200, Andre Klapper skribis:
>> > > , as exposed in #324), but coherence across modules should be kept.
>> >
>> > I agree that it would be good to consider renaming all master branches.
>>
>> Then mightn't it be better to bring up the topic with GNOME and/or Git
>> upstream?
>
>
> This is exactly what I meant when said "consider".
>
>>
>> Because it would be a bit of a mess if every project could
>> decide for themselves what to call their master/mainline branch. For
>> infrastructure reasons, it seems to me that it would be best if the
>> name of that branch were uniform.
>>
>> I would like that name to be something other than "master", which is a
>> bit clunky, inaccurate, and prone to cause offence, but I'd rather have
>> that than a broken infrastructure.
>
>
> I don't think "master" causes any kind of offence, but this is just a 
> question of appreciation.
>
> Of course, If we consider this topic is enough important to take into 
> account, we should open a new thread involving d-d-l and maybe other teams 
> (Releaste team, Infrastructure...). But is this thread we are just discussing 
> if Geary's maintainer should revert the change, at least until a final 
> decission has been taken.
>
> I've exposed some arguments to revert it, the main one is that Damned Lies is 
> currently broken due to this name change. You can see it in the screenshot.
> In the other hand, opening the door to change the name of the master branch 
> in every module will result in a very big mess, broken scripts, etc.
>
> Cheers
>
>>
>> With kindness,
>> Carmen
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Unauthorized translation changes in dconf-editor

[Ask Hjorth Larsen via gnome-i18n]

Am Mo., 18. März 2019 um 20:36 Uhr schrieb Claude Paroz :
>
> Le 18.03.19 à 15:17, mcatanz...@gnome.org a écrit :
> > Please keep gnome-i18n@gnome.org CCed
> >
> > On Mon, Mar 18, 2019 at 5:02 AM, Arnaud Bonatti
> >  wrote:
> ...
> >> If a translation contains a web link to what is currently an
> >> hypnotherapist website, it’s my role to remove that link before it
> >> hits the stable release. Even if I didn’t had the time to join the
> >> translator or its team to fix it in l10n. (Yes, it’s a true story. Not
> >> a big issue, but a real life one.)
>
> Hello Arnaud,
>
> I'm sure you have good intentions and you want the better for you
> released software.
> However the example above is a typical example whete it would be crucial
> that gnome-i18n is aware of the issue, because the person that committed
> that is either malicious and his account should immediately be blocked,
> or his account has been hacked and he should be aware of that.
>
> So if you report a serious issue to a translator team and don't get a
> prompt answer, you should imemdiately escalate the issue to gnome-i18n
> so we can take proper action.

I agree with this - also, reporting the smaller errors to the
translation teams could mean that they are corrected elsewhere, as
they are likely repeated in the 100+ GNOME modules.  I wonder if that
link is found in multiple modules?

(Of course it is tedious to wait for the translation teams when
there's a release deadline and you're doing the final polishing.)

Best regards
Ask

>
> Thanks for your understanding.
>
> Claude
> --
> www.2xlibre.net
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Mass commit of GNOME modules

[Ask Hjorth Larsen via gnome-i18n]

Hi,

FWIW I have a similar tool, also with a few settings at the top:
https://gitlab.com/askhl/pygnomegitpo

Typical use is

  cttgnomegit.py --pull --commit  *.po

followed by (requires confirmation for each file)

  cttgnomegit.py --push *.po

Best regards
Ask

Am Do., 28. Feb. 2019 um 16:47 Uhr schrieb Daniel Mustieles García via
gnome-i18n :
>
> Sure :-)
>
> Here it is: https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
>
> Just need to change some variables at the beginning and commit message and it 
> will do the magic
>
> Hope it helps you!
>
> El jue., 28 feb. 2019 a las 16:38, Rafael Fontenelle () 
> escribió:
>>
>> Hello all,
>>
>> I'm working on fixing issues (e.g. inconsistent translations) in many
>> .po files of my language in many modules available in D-L, but doing
>> click-n-submit for more than a hundred of modules would take too much
>> time.
>>
>> Does someone have a tool/script/hint doing mass Git commit to GNOME
>> modules that could share?
>>
>> Thanks in advance.
>>
>> Best regards,
>> Rafael Fontenelle
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translation teams: Please check/fix your open bug reports in GNOME Bugzilla

[Ask Hjorth Larsen via gnome-i18n]

Fixed for da. Don't know how to close the bug though.

Best regards
Ask



El lun., 25 feb. 2019 20:25, Daniel Șerbănescu 
escribió:

> Thank you for pointing this out Andre,
>
> I just marked the one Romanian bug as fixed (which is a temporary fix)
> and opened a new issue on Gitlab.
> https://gitlab.gnome.org/GNOME/orca/issues/32
>
> Regards,
> Daniel
>
> În data de Lu, 25-02-2019 la 19:44 +0100, Andre Klapper a scris:
> > As GNOME is migrating from Bugzilla to Gitlab, please check (and fix)
> > your remaining open bug reports in Bugzilla:
> >
> https://bugzilla.gnome.org/report.cgi?x_axis_field=component_redirect=1_format=report-table_desc_type=allwordssubstr=l10n=---_id=_id_type=anyexact_top=AND=noop=noop==table=wrap
> >
> > Languages with open bugs are:
> > * Albanian [sq]
> > * Arabic [ar]
> > * Basque [eu]
> > * Brazilian Portuguese [pt_BR]
> > * British English [en_GB]
> > * Catalan [ca]
> > * Chinese (Simplified) [zh_CN]
> > * Croatian [hr]
> > * Czech [cs]
> > * Danish [da]
> > * Dutch [nl]
> > * French [fr]
> > * Galician [gl]
> > * German [de]
> > * Greek [el]
> > * Hindi [hi]
> > * Italian [it]
> > * Japanese [ja]
> > * Kannada [kn]
> > * Latvian [lv]
> > * Macedonian [mk]
> > * Marathi [mr]
> > * Nepali [ne]
> > * Persian [fa]
> > * Polish [pl]
> > * Portuguese from Portugal [pt]
> > * Punjabi [pa]
> > * Romanian [ro]
> > * Russian [ru]
> > * Slovak [sk]
> > * Swedish [sv]
> > * Telugu [te]
> > * Turkmen [tk]
> > * Ukrainian [uk]
> >
> > Thanks,
> > andre
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: 3.30 release notes ready for translation

[Ask Hjorth Larsen via gnome-i18n]

Hi,

Den fre. 31. aug. 2018 kl. 09.36 skrev Daniel Mustieles García via
gnome-i18n :
>
> Hi Alexandre,
>
> I agree with you but marking those strings as translated doesn't reflect the 
> an accurate status but the frustration is not the main reason to do that. 
> Note that leaving those strings untranslated don't allow us to know if the 
> module has been updated with new strings needing attention or not, so if I 
> leave a module at 99% with some image strings not translated I will revisit 
> that module to check if that 99% is due to new translatable strings or due to 
> the untranslated images.
>
> So I'm sorry for disagreeing but in muy case I will keep translating those 
> strings to avoid wasting time re-checking modules again and again until we 
> can reach a better solution for that.
>

Very true.  We cannot sacrifice our everyday workflow efficiency
(beeing able to see if we need to translate strings or not in a given
module) for the sake of slightly more accurate translation statistics.
We'd rather worry about how to mark those strings the day we get the
time and resources to start localizing the screenshots.

Best regards
Ask

> Regards
>
> 2018-08-31 9:16 GMT+02:00 Alexandre Franke :
>>
>> Hi fellow translators,
>>
>> On Tue, Aug 28, 2018 at 4:20 PM Link Dupont  wrote:
>>>
>>> They are now done and ready for translation! The notes can be found in
>>> the gnome-3-30 branch of the release-notes repository. I will be adding
>>> images this week.
>>
>>
>> While looking into details of the 3.28 translations, I found out that many 
>> teams mark screenshots as “translated but uses the original”. Please don’t 
>> do that. I understand that seeing something not at 100% is frustrating but 
>> this is not a good reason to do it. If you don’t have the time or if it is 
>> too difficult to reproduce, then just leave the screenshot untranslated. The 
>> result will be the same for readers (original screenshot will be shown) but 
>> at least we get an accurate representation of the state.
>>
>> This of course doesn’t apply to logos and other such images that indeed can 
>> be used as is in the localized version.
>>
>> Cheers,
>>
>> --
>> Alexandre Franke
>> GNOME Hacker
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Migrate to gitlab.gnome.org?

[Ask Hjorth Larsen]

Hi,

2018-05-15 21:23 GMT+02:00 Matej Urban :
> Guys,
>
> how do I check whether gnome project is currently still on git or already on
> gitlab? Is there a git command or can I find this info on the DL page?
>
> M!

What I do is to assume it is not on gitlab, then update the git info
whenever it complains.

In case you or someone else finds it useful, here is a semiautomatic
script which can commit, push etc., and automatically update the git
remote:

http://dcwww.camd.dtu.dk/~askhl/files/cttgnomegit.py

It needs a bit of adaptation (committer names) and of course careful
verification (I never tested it with other languages codes than da).

Best regards
Ask

>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Application to Take Over as zh_CN Team Coordinator

[Ask Hjorth Larsen]

Hi Mingcong,

2018-03-18 9:09 GMT+01:00 Mingcong Bai :
> Hi all,
>
> The current coordinator of the zh_CN team, Aron Xu
> (https://l10n.gnome.org/users/cnfavor/) has failed to coordinate or to
> actively commit reviewed translation, since almost two years ago. Though
> some other contributors and I have been able to reach Aron, he has only
> stated to commit the changes when he's available - and the translations have
> rarely been committed since 3.24. This is evident if you would take a look
> at the declining percentage of translated strings over the releases
> (https://l10n.gnome.org/teams/zh_CN/), and the large amount of stale "To
> Commit" markers, as seen in the 3.28 status page
> (https://l10n.gnome.org/languages/zh_CN/gnome-3-28/ui/).
>
> Our committer, similarly, had failed to fulfill their task, as suggested
> with the references above. In particular, the commiter YunQiang Su,
> similarly, we were able to get in contact with, but have failed to commit
> much changes at all.
>
> To make the matters worse, obvious mistakes still exist in our zh_CN
> translations shipped with current versions of GNOME Applications. To name a
> few...
>
> 1. In nmtui (NetworkManager's ncurses UI), the phrase “无线网络” (wireless
> network) has been typo'd to “无效网络” (invalid network) - an easy mistake to
> make when typing with Pinyin, as one could type only the first syllable to
> get a list of marching characters. This is yet to be committed upstream.
> (https://l10n.gnome.org/vertimus/NetworkManager/master/po/zh_CN)
> 2. In GNOME Tweaks, the word "Tweaks" has been typed as "Teaks". This, due
> to the "To Commit" marker, no fixes could be applied, nor were the prior
> translation committed by those supposed to do the work.
> (https://l10n.gnome.org/vertimus/gnome-tweaks/master/po/zh_CN)
>
> Therefore, I'm writing to apply and replace the unresponsive (or I should
> venture to say, irresponsible) coordinator and committer. I have been making
> contributions to the GNOME zh_CN translation since at least 2015, and I with
> the not-so-little amount of contributions made - not to mention
> contributions to non-GNOME projects like WineHQ, MATE, and FreeDesktop.org -
> I do believe that I have the necessary skill to review, commit, and
> coordinate a translation team. It is also because of the contributions I
> have made personally, and those made by my colleagues at the team - that I
> find it necessary to locate a more responsive peer for this task, again, the
> zh_CN localisation progress has been regressing since 3.24, and this should
> not happen for much longer.
>
> Please consider this request and make personnel changes as applicable, thank
> you.

There's a procedure described here:
https://wiki.gnome.org/TranslationProject/CoordinationActions

Please see "Team Coordinator changes".  The current coordinator is
supposed to be CC'ed along with this list.

Ideally the two of you should agree about the takeover beforehand.  I
understand that this may be difficult if the coordinator is
unresponsive and/or disagrees.  Nevertheless this is the way to start.

If the coordinator is completely unresponsive and things drag out,
maybe someone else here (such as myself) will be able to commit
translations in the meantime.

Someone should correct me if some of the above is wrong.

Best regards
Ask

>
> Best Regards,
> Mingcong Bai
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Gitlab access for translators

[Ask Hjorth Larsen]

Hi,

2018-03-10 21:38 GMT+01:00 Matej Urban :
> Hello,
>
> yes, I did, the error is:
>
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> fatal: Could not read from remote repository.
>
> I first changed the url by hand in config and I was asked if I want to add
> new address and accept all the keys. I of course confirmed.

Probably you need to add your public ssh key (e.g. ~/.ssh/id_rsa.pub)
to the gitlab configuration (via the browser).

Best regards
Ask

>
> Matej
>
> On Sat, Mar 10, 2018 at 9:35 PM, Piotr Drąg  wrote:
>>
>> 2018-03-10 21:11 GMT+01:00 Matej Urban :
>> > Hello,
>> >
>> > I tried to update translations today and found, that some I can update
>> > the
>> > same way as I always did, some I can not. The error states, that the
>> > repository has moved to GitLab and I should update the Git remote to the
>> > new
>> > address.
>> > I am trying "stuff", but I can not get it working. I have no idea, what
>> > could be wrong. Can you please tell me what do I need to change and how?
>> > I
>> > changed the address and confirmed it.
>> >
>>
>> Have you tried
>>
>> git remote set-url origin g...@gitlab.gnome.org:GNOME/project-name.git
>>
>> ?
>>
>> Best regards,
>>
>> --
>> Piotr Drąg
>> https://piotrdrag.fedorapeople.org
>
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: [dconf-editor] cleaning of translations, 2nd approach

[Ask Hjorth Larsen]

Hi,

2018-03-06 11:31 GMT+01:00 Arnaud Bonatti :
> Hello everybody! As you already know, I’m trying these days to improve
> the content of the “po” directory in the “dconf-editor” module I
> maintain. I must start by thanking again everybody for the work done
> there, it’s impressive, really! But my concerns are of course not
> about the work that is done, as I only speak a small small part of the
> languages that are present. :·)
>
> Some translation teams have too few people (sometimes only one person)
> to translate every GNOME software at every release, and there are
> clearly some applications that should be translated before Dconf
> Editor. :·) So there are translations that are not updated regularly,
> and some of them are not updated at all –these two cases are somewhat
> different. As a result:
>  – there are strings not used anymore that have a translation, takes
> place but usually not a big deal;
>  – there are strings that have since been edited in English but that
> have a translation, here that means that there’s work done that isn’t
> displayed;
>  – it’s quite impossible to use a tool like `grep` globally on
> translations to check for typos, as there are unused strings that
> makes the output unreadable.
> That’s notably important in this module, that is quite old and has
> seen multiple states in its UI and strings history.
>
> As a first step for a global improvement of the translations, to see a
> little better what’s translated and what is not, I’d like to remove
> all the untranslated strings present in the po files, mostly files
> that hasn’t been edited for a while. That’d be a “25 files changed,
> 19347 deletions(-)” diff, that wouldn’t change anything in the result
> I think (apart a 3.3% reduction of the tarball file), but that would
> notably improve grepping.

Changing the subject to something purely practical: Pruning/cleaning
the po-files can probably be fully scripted, so there would be no harm
in committing a script somewhere which does this, then sending bug
reports to translation teams without actually committing the cleaned
po files.

FWIW The changes to Danish (da) do not need to be reverted, although
they would have been overwritten if we had updated the translation at
a different moment.

Best regards
Ask

>
> Do you see any technical problem with that that I’d have neglected?
> Would you agree on me doing that, teams concerned and other teams?
> (Are concerned directly the po files: an, ar, as, be, bn_IN, bs, eo,
> et, fa, hi, is, ja, mr, pa, ro, ru, ta, te, tg, th, ug, uk, vi,
> zh_HK.) Would some people prefer that I contact every team
> independently? Other reactions, opinions?
>
> Cheers,
> Arnaud
>
> --
> Arnaud Bonatti
> 
> courriel : arnaud.bona...@gmail.com
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: [evolution-ews] Two new translatable strings added for 3.27.91

[Ask Hjorth Larsen]

2018-02-09 21:22 GMT+01:00 Shaun McCance :
> On Wed, 2018-02-07 at 23:33 +0100, Alexandre Franke wrote:
>> On Wed, Feb 7, 2018 at 7:15 PM, Milan Crha  wrote:
>> >
>> > The strings in question are:
>> >Tenant cannot be empty
>>
>> That one probably deserves a translator comment. I know the word
>> tenant in the context of renting an appartment, but I have no clue
>> what it could be here.
>
> I don't know the specifics of Microsoft Exchange, but in auth systems
> in general a tenant is usually a sort of group that you log in with. If
> I log in as "shaunm" in the "admin" tenant, I might have different
> privileges than if I log in as "shaunm" in the "user" tenant.
>
> It's a terrible term that leads to lots of StackExchange questions and
> general confusion among users and translators.
>
> If you can't find how Microsoft translates it for your language, maybe
> check OpenStack, which also uses the term.

Yes, this is prime translator headache material :)

Maybe add

# TRANSLATORS: A tenant is a group of users who share a common access
to a software system.
# https://en.wikipedia.org/wiki/Multitenancy

And even better if there are some usage hints - is it important that
this word or an exact equivalent is used (maybe translator will write
the English term in parenthesis then), or can it be replaced by
something inexact like 'Security group'.

Best regards
Ask

>
> --
> Shaun
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Migrate to gitlab.gnome.org?

[Ask Hjorth Larsen]

As a humble translator/coordinator and gitlab user for several
projects (which are not otherwise related to GNOME), +1.

Best regards
Ask

2018-01-12 21:42 GMT+01:00 Shaun McCance :
> +100 on the migration.
>
> I think the team might want to have a conversation about to what extent
> we want to do merge requests versus committing directly. I also think
> our opinion on that will evolve over time. So, you know, don't get too
> hung up on it.
>
> --
> Shaun
>
> On Thu, 2018-01-11 at 19:51 +0100, Petr Kovar wrote:
>> Hi all,
>>
>> More and more GNOME projects seem to be migrating from old git
>> infrastructure and Bugzilla to https://gitlab.gnome.org/.
>>
>> Would there be any objections to moving our docs repos (gnome-user-
>> docs
>> etc.) to gitlab.gnome.org after the upcoming stable release?
>>
>> This would affect the documentation work in the following way:
>>
>> Contributors would follow a GitHub-like workflow by forking the docs
>> repo,
>> creating a topic branch, and submitting a merge request when ready
>> for peer
>> review.
>>
>> Users would use the GitLab integrated issue tracker instead of
>> Bugzilla.
>> Old bugs would be migrated to GitLab (and closed in Bugzilla).
>>
>> There would be no need to upload patches to Bugzilla to contribute.
>>
>> The overall process would feel more like 2017 rather than 2007 or
>> 1997.
>>
>> The translation process shouldn't be affected.
>>
>> Thoughts, comments, concerns?
>>
>> Best,
>> pk
>> ___
>> gnome-doc-list mailing list
>> gnome-doc-l...@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-doc-list
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: libgweather message context problems?

[Ask Hjorth Larsen]

Hi Bastien,

2017-12-13 14:38 GMT+01:00 Bastien Nocera :
> Hey,
>
> I was wondering whether this particular problem:
> https://bugzilla.gnome.org/show_bug.cgi?id=573969
> was a big problem for translators in the past couple of years.

I have never thought about these changes.  Probably the best solution
is not to care.

>
> I don't think that it's worth invalidating nearly all the current
> strings to avoid problems in a couple of edge cases.

I completely agree.

>
> (I do know about:
> https://bugzilla.gnome.org/show_bug.cgi?id=556843
> which look infinitely more problematic and disheartening for
> contributors)

(Yes, the tiny hamlets should probably be removed.)

Best regards
Ask

>
> Cheers
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Xdg-user-dirs really upset...

[Ask Hjorth Larsen]

Hi Fabio Tomat,

2017-11-08 10:39 GMT+01:00 Fabio Tomat :
> It passed a year, I highlight it A YEAR, since the publication of friulian
> translation on translation project for the xdg-user-dirs.
> On september 2017 the maintainer (Mikel Olasagasti) said he was waiting a
> gpg key from freedesktop. Well 2 months has passed, I tried to contact him
> again but no answers were given.
> I start to think he will never publish friulian translations and after a
> year I can say my patience is finished. Is there someone that has the power
> to let the work be done? Should I give up?

I understand what you say, but some additional context is surely required.

So the translation is on TP and listed here:
https://translationproject.org/domain/xdg-user-dirs.html

This is the exact file, from one year ago:
https://translationproject.org/PO-files/fur/xdg-user-dirs-0.14.fur.po

Which exact place is it that the translation is *not* reaching?  Is it
the code repository, or a certain software distribution?

What is the relation to GNOME i18n?

Best regards
Ask

>
> Thanks in advance for your attention
>
> Best regards
>
> Fabio Tomat
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: documentation translations

[Ask Hjorth Larsen]

Hi

Maybe the error message on damned lies could say exactly what to do?

Best regards
Ask

El 20 sept. 2017 21:45, "Rafael Fontenelle"  escribió:

> Considering that the question about "Sorry, adding new translations
> for documentation is not yet supported" is very common, I think it
> would be nice to have a URL with the information ready for the user,
> like a troubleshooting section in the Wiki or a bug report with some
> information. Ideally, I think this documentation should have 1)
> symptom 2) explanation 3) workaround (which is to provide the URL in
> the gnome-i18n list for someone else to commit)
>
> How does it sound?
> Any idea if there is a good, complete information URL or a place in
> Wiki to add such info?
>
> Best regards,
> Rafael Fontenelle
>
> 2017-09-20 11:49 GMT-03:00 Andre Klapper :
> > On Wed, 2017-09-20 at 16:23 +0200, Fabio Tomat wrote:
> >> I started the translation of the documentations to friulian.
> >> I could not commit the changes of gnome-photos.
> >> The error was:
> >> Sorry, adding new translations for documentation is not yet
> >> supported.
> >
> > See https://mail.gnome.org/archives/gnome-i18n/2017-March/msg00169.html
> >
> > andre
> > --
> > Andre Klapper  |  ak...@gmx.net
> > http://blogs.gnome.org/aklapper/
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
> .
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: gtk+ 3.22

[Ask Hjorth Larsen]

Hi,

I usually commit from command line because it is a lot of "clickywork"
to use damned lies.  Particularly in these days where we often have
some small unicode changes across a whole module set.

What damned-lies needs to be really efficient is a mass-submit
function: Upload a number of files (nautilus.master.LL.po,
gtk+.gnome-3-22.LL.po, gedit.master.LL.po, ) and it should be
possible to commit them all simultaneously to the appropriate
branches.  Probably with some minimal per-module interaction, like
sanity check/confirmation.

I hope I don't sound too demanding - this is just my perspective as a
user who is familiar with scripting/git.

Best regards
Ask

2017-09-13 15:14 GMT+02:00 Rafael Fontenelle :
> 2017-09-13 8:15 GMT-03:00 Hannie Dumoleyn :
>>>
>> Hello Rafael,
>>
>> Thanks for your answer. Perhaps I should report a bug. I pushed the fully
>> translated file using Damned Lies about an hour ago (sep 13, 12:00), but it
>> still doensn't show here: https://l10n.gnome.org/languages/nl/gnome-3-26/ui/
>>
>> So, now I am going to use good old git to upload it yet again.
>>
>> Hannie
>>
>
> Oh-oh. I saw your team's Rygel translation history and notice that you
> selected: "Ready for submission" > "Reserve to submit" > "Inform of
> submission". These actions exist since before D-L had the feature of
> pushing translation to Git repositories. By using these actions you are
> simply marking this round of translations as finished, and cleaning up
> the list. Please notice these actions are still useful for non-GNOME
> modules (which you have to use an external platform to send the
> translation for their developers) and GNOME documentations that you
> had to add via Git command-line.
>
> In order to effectively push your translations to the Git repository
> vi D-L, please select:
>
>  "Ready for submission" > "Submit to repository"
>
>
> Rafael Fontenelle
>
> .
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Incomplete .pot/.po files for several modules

[Ask Hjorth Larsen]

Hi,

2017-08-12 22:33 GMT+02:00 Piotr Drąg :
> A quick PSA,
>
> damned-lies generates incomplete .pot/.po files for totem,
> totem-pl-parser, nautilus-sendto, and gnome-bluetooth, and it’s
> unlikely to change until
> https://bugzilla.gnome.org/show_bug.cgi?id=783099 is fixed.

Back in the day we could always could on intltool-update to do the
job.  Nowadays things are... complicated :).  Would it not make sense
to request that all projects provide a specific command (whether
intl-tool update or not) that updates the messages for a particular
language?  That way damned lies won't have to do so much maintenance
work, and the developers are familiar with their own build system
anyway.  Also life becomes easy for those who have the habit of
committing to git directly.

Best regards
Ask

>
> Best regards,
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Commit and enable Finnish GIMP docs

[Ask Hjorth Larsen]

I think the issue is that they must be added to the various LINGUAS
files, and damned lies does not know how to do that.

Best regards
Ask

2017-03-28 12:15 GMT+02:00 Jiri Grönroos :
> Unfortunately enabling a language via configure.ac doesn't affect those
> limitations that Damned Lies faces when it comes to adding new docs/help
> translations. When I try to make a commit on DL, I receive this error:
>
> “Sorry, adding new translations for documentation is not yet supported.”
>
> I guess the only way to commit a totally new help po file is to use git.
> Therefore I sent the message to this list instead of filing a bug.
>
> Jiri Grönroos
>
> 2017-03-27 19:55 GMT+03:00 Daniel Mustieles García
> :
>>
>> I've added fi language to configure.ac. Please try to commit now your
>> translations from DL... I think it should now let yo do it
>>
>> 2017-03-27 18:41 GMT+02:00 Jiri Grönroos :
>>>
>>> Lately a group of people from the University of Oulu focused on
>>> translating GIMP docs. These translations count as the first versions of
>>> Finnish GIMP docs and therefore face the limitations of DL concerning
>>> commiting of docs.
>>>
>>> These translations, po files, have a status of "To commit" on DL:
>>> https://l10n.gnome.org/languages/fi/gnome-gimp/doc/
>>>
>>> As I lack the access to git, could somebody with git access commit those
>>> files? Thank you in advance.
>>>
>>> When those files are in git, I'll file a bug in order to enable Finnish
>>> ISO-639-1 locale code "fi" as per
>>> https://github.com/GNOME/gimp-help-2/blob/master/configure.ac#L57
>>>
>>> Jiri Grönroos
>>>
>>> ___
>>> gnome-i18n mailing list
>>> gnome-i18n@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>
>>
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Ask Hjorth Larsen]

Hi

2017-03-21 14:12 GMT+01:00 Piotr Drąg :
> 2017-03-21 9:38 GMT+01:00 Danylo Korostil :
>> Hello,
>>
>> I'm translating Gnome and check the completeness against DL, but statistic
>> is mismatched:
>>
>> See: http://i.imgur.com/nZO4m2D.png
>>
>> Is it a DL bug or intltool-update deprecation?
>>
>
> Hi Danylo,
>
> gnome-shell is indeed one of the modules that don’t use intltool
> anymore. You should download the .po file from damned-lies and don’t
> run intltool-update on it, otherwise some parts may end up
> untranslated. One unscientific method to check if a module is
> gettext-exclusive is looking at the file paths in the .po file.
> Intltool uses relative paths, so file names start with “../”, while
> gettext uses absolute paths.
>
> Hope this helps,
>

It seems like a big step backwards that we can no longer use a single
procedure to merge/verify translations offline.  How could it come to
this?  (This is both a rhetorical question and not)

Would it not be possible to include the merge functionality with the
individual projects?  E.g. a single script present in all projects' po
folders, update-po , and it either just calls intltool or
does something else.  The damned lies backend would also be simpler,
perhaps, if each project has uniform code to update its own
translations.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: gnome-photos: Fixed a typo in a string marked for translation

[Ask Hjorth Larsen]

Hi

2017-02-20 22:22 GMT+01:00 Debarshi Ray :
> Hello everybody,
>
> Jeremy just fixed [1] a spelling mistake in a string that was marked for
> translation:
> - "Your %s crendentials have expired"
> + "Your %s credentials have expired"
>
> He also fixed all affected translations. Hence, I expect the change to be
> transparent, but I thought I'd just let you know.
>
> Thanks for your work, and sorry for the typo!

Thank you.  I can see from the source that %s is a name.  Is it a
service (e.g. Google or Instagram)?  It would be very nice to have
that piece of information as a translator comment.

Best regards
Ask

>
> Cheers,
> Rishi
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=778967
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: UI and string changes in gnome-games

[Ask Hjorth Larsen]

Hi

2017-02-16 23:18 GMT+01:00 Adrien Plazas via gnome-i18n :
> Hi,
>
> The error display page of Games now displays messages explaining the reason
> of the failure. With this change came many new strings.
>
> A notable change is the addition of many strings describing gaming
> platforms/system, which should be localized — for example "Sega Genesis"
> should be "Mega Drive" in most of the world.

Which exact module/template does this refer to?

(Are you the developer?  In that case, I would recommend writing these
things as translator comments so they appear in the file itself.)

Best regards
Ask

>
> Cheers,
> Adrien Plazas
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: GParted 0.28.0 to be Released Feb 14, 2017

[Ask Hjorth Larsen]

2017-02-11 0:49 GMT+01:00 Florian H. :
>
>
>> On Feb 10, 2017, at 13:07, Mike Fleetwood via gnome-i18n 
>>  wrote:
>>
>>> On 10 February 2017 at 16:01, Curtis Gedak  wrote:
>>> Hi Mike,
>>>
>>> Would you be able to look into this request?
>>>
>>> Thanks,
>>> Curtis
>>>
>>>  Forwarded Message 
>>> Subject: Re: GParted 0.28.0 to be Released Feb 14, 2017
>>> Date: Thu, 9 Feb 2017 23:46:22 +0100
>>> From: Alexandre Franke 
>>> To: Curtis Gedak 
>>> CC: gnome-i18n 
>>>
>>> Hey,
>>>
>>> There's a series of strings that look odd and we're not sure how to
>>> translate them best in French. Can you enlighten us? It's all the
>>> “partition contains open LUKS encryption for a * step” strings.
>>>
>>> Cheers,
>>>
>>> --
>>> Alexandre Franke
>>> GNOME Hacker & Foundation Director
>>
>> They are all messages reporting internal logic errors in the GParted
>> application itself.  For example:
>>
>>  partition contains open LUKS encryption for a create file system only step
>>
>> The error message is stating that an internal consistency check has
>> detected an error condition; that the partition contains an open LUKS
>> encryption mapping when it is not expected.  The code is at the create
>> a file system step (or either a Format or New operation).  The
>> application should not allow the user to trigger these errors by their
>> actions.  These error messages exist to report programming errors in
>> the GParted application itself.
> So then they should better not be translated. Otherwise you may get bug 
> reports send back to you in 50+ different languages ...

On the other hand, if I were to get an English message in a program
which I knew to be translated, that would also be grounds for
reporting an error.  Also if the user's program stops working, the
user has a right (in a sense) to understand the error message.

(It is not my impression that bug reports in different languages are
common at all, but you may know better of course.)

Best regards
Ask


> Cheers,
> Florian
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Looking for a translator co-mentor for a GSoC project

[Ask Hjorth Larsen]

Hi

2017-01-20 12:16 GMT+01:00 Lasse Schuirmann <lasse.schuirm...@gmail.com>:
> Hi,
>
> CCing John Vandenberg who is in contact with the Dennis maintainer.
>
> We discussed this and it seems like pyg3t has some features that would
> be beneficial. Integrating this could be very well part of the
> project, especially if you will be able to help mentoring!
> Sincerely,
>
> Lasse Schuirmann

I will be glad to help, but to be clear, I can only help (usefully)
with pyg3t - not with the other software involved, which is likely
more complex.  So I would strongly recommend that at least someone on
the other side were also involved.  Also, I don't yet understand what
the, uh, goal of the project, is, exactly :).  Is there something
specific written somewhere?

Best regards
Ask

>
> la...@schuirmann.net
> http://coala.io/ - http://viperdev.io/ - http://gitmate.com/
>
>
> On 20 January 2017 at 12:00, Ask Hjorth Larsen <asklar...@gmail.com> wrote:
>> I should of course remember to leave a link: https://github.com/pyg3t/pyg3t .
>>
>> Best regards
>> Ask
>>
>> 2017-01-20 11:56 GMT+01:00 Daniel Mustieles García 
>> <daniel.mustie...@gmail.com>:
>>> +1 for this idea
>>>
>>> PyG3t has very interesting and useful tools that could be integrated.
>>>
>>> Cheers!
>>>
>>> 2017-01-20 11:53 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>>>>
>>>> Hi Alexandre and Lasse
>>>>
>>>> 2017-01-20 11:29 GMT+01:00 Alexandre Franke <afra...@gnome.org>:
>>>> > Hi fellow translators and coordinators,
>>>> >
>>>> > Lasse Schuirmann (please keep him CCed) is a fellow GNOME contributor
>>>> > who's been involved with Summer of Code both as a student and as an
>>>> > admin with GNOME. He's also the founder of Coala, a code analysis
>>>> > tool, and a GSoC admin with them.
>>>> >
>>>> > Coala wants to have an intern working on i18n QA tool integration this
>>>> > summer. They are currently thinking about dennis [0] but would be
>>>> > interested in integrating other ones too (translate-toolkit, pology…).
>>>> > They are looking for someone who knows about translation and the
>>>> > features of those tools to help them co-mentor the student.
>>>> >
>>>> > So if you're interested or want to know more about it please let us
>>>> > know!
>>>>
>>>> I am certainly willing to help in case there's interest in integrating
>>>> our own modest toolkit, pyg3t.  It is not as general as
>>>> translate-toolkit, but there are some things that could probably be
>>>> useful for damned lies (e.g. clean diffing of po-files).
>>>>
>>>> Best regards
>>>> Ask
>>>>
>>>> >
>>>> >
>>>> > [0] discussion about this at
>>>> > https://github.com/coala/coala-bears/issues/892#issuecomment-266337643
>>>> >
>>>> >
>>>> > Cheers,
>>>> >
>>>> > --
>>>> > Alexandre Franke
>>>> > GNOME Hacker & Foundation Director
>>>> > ___
>>>> > gnome-i18n mailing list
>>>> > gnome-i18n@gnome.org
>>>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>> ___
>>>> gnome-i18n mailing list
>>>> gnome-i18n@gnome.org
>>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>
>>>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Looking for a translator co-mentor for a GSoC project

[Ask Hjorth Larsen]

I should of course remember to leave a link: https://github.com/pyg3t/pyg3t .

Best regards
Ask

2017-01-20 11:56 GMT+01:00 Daniel Mustieles García <daniel.mustie...@gmail.com>:
> +1 for this idea
>
> PyG3t has very interesting and useful tools that could be integrated.
>
> Cheers!
>
> 2017-01-20 11:53 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>>
>> Hi Alexandre and Lasse
>>
>> 2017-01-20 11:29 GMT+01:00 Alexandre Franke <afra...@gnome.org>:
>> > Hi fellow translators and coordinators,
>> >
>> > Lasse Schuirmann (please keep him CCed) is a fellow GNOME contributor
>> > who's been involved with Summer of Code both as a student and as an
>> > admin with GNOME. He's also the founder of Coala, a code analysis
>> > tool, and a GSoC admin with them.
>> >
>> > Coala wants to have an intern working on i18n QA tool integration this
>> > summer. They are currently thinking about dennis [0] but would be
>> > interested in integrating other ones too (translate-toolkit, pology…).
>> > They are looking for someone who knows about translation and the
>> > features of those tools to help them co-mentor the student.
>> >
>> > So if you're interested or want to know more about it please let us
>> > know!
>>
>> I am certainly willing to help in case there's interest in integrating
>> our own modest toolkit, pyg3t.  It is not as general as
>> translate-toolkit, but there are some things that could probably be
>> useful for damned lies (e.g. clean diffing of po-files).
>>
>> Best regards
>> Ask
>>
>> >
>> >
>> > [0] discussion about this at
>> > https://github.com/coala/coala-bears/issues/892#issuecomment-266337643
>> >
>> >
>> > Cheers,
>> >
>> > --
>> > Alexandre Franke
>> > GNOME Hacker & Foundation Director
>> > ___
>> > gnome-i18n mailing list
>> > gnome-i18n@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Looking for a translator co-mentor for a GSoC project

[Ask Hjorth Larsen]

Hi Alexandre and Lasse

2017-01-20 11:29 GMT+01:00 Alexandre Franke :
> Hi fellow translators and coordinators,
>
> Lasse Schuirmann (please keep him CCed) is a fellow GNOME contributor
> who's been involved with Summer of Code both as a student and as an
> admin with GNOME. He's also the founder of Coala, a code analysis
> tool, and a GSoC admin with them.
>
> Coala wants to have an intern working on i18n QA tool integration this
> summer. They are currently thinking about dennis [0] but would be
> interested in integrating other ones too (translate-toolkit, pology…).
> They are looking for someone who knows about translation and the
> features of those tools to help them co-mentor the student.
>
> So if you're interested or want to know more about it please let us know!

I am certainly willing to help in case there's interest in integrating
our own modest toolkit, pyg3t.  It is not as general as
translate-toolkit, but there are some things that could probably be
useful for damned lies (e.g. clean diffing of po-files).

Best regards
Ask

>
>
> [0] discussion about this at
> https://github.com/coala/coala-bears/issues/892#issuecomment-266337643
>
>
> Cheers,
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Unicode typography in translations

[Ask Hjorth Larsen]

2016-11-16 13:43 GMT+01:00 Rafael Fontenelle <rafae...@gnome.org>:
>
> 2016-11-15 10:21 GMT-02:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>>
>> Hi Rafael
>>
>> 2016-11-15 2:26 GMT+01:00 Rafael Fontenelle <rafae...@gnome.org>:
>>
>> > It would be nice to have a script with regexp that could compare msgstr
>> > and
>> > msgid in a PO file, and report strings that are not in compliance with
>> > GNOME's HIG typography.  I don't have such scripting skill, but if
>> > someone
>> > has it, please consider do it.
>> >
>> > Regards,
>> > Rafael Fontenelle
>>
>> It is easy to recognize when the English string contains something,
>> and the translated string does not (e.g. to find a unicode ellipsis
>> that was translated to an ASCII ellipsis).  But if the English string
>> uses ASCII, it is not always easy.  For example recognizing exactly
>> when the en-dash could or should be used instead of an ASCII hyphen.
>>
>> It is probably a good assumption that any sequence of exactly three
>> dots should be a unicode ellipsis, no matter the context, but that's
>> the only trivial case.
>>
>> Best regards
>> Ask
>
>
> I agree that is not hard to recognize them while translating a PO file. I
> just would like to have a solution that allows a conformity checking that
> could be run anytime, as such Unicoded characters could be missed by the
> translator (myself included).
>
>
> Rafael Fontenelle

A simple conformity check:

  gtgrep -cn --msgstr '\.\.\.'   filename.po

I had a bit of a battle to get the regex escapes right in bash, but
this should weed out most false positives:

  gtgrep -cn --msgstr '(?https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Unicode typography in translations

[Ask Hjorth Larsen]

Hi Rafael

2016-11-15 2:26 GMT+01:00 Rafael Fontenelle :
> 2016-11-14 12:31 GMT-02:00 Piotr Drąg :
>>
>> Hello translators,
>>
>> You might have noticed a lot of changes in master branches regarding
>> the use of Unicode typography. GNOME HIG has recommendations for
>> English:
>>
>> https://developer.gnome.org/hig/stable/typography.html
>>
>> I have been submitting patches for implementing these recommendations
>> in the original strings:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=772263
>>
>> This is a great opportunity to improve our translations! For example,
>> I have been using ASCII typography (characters you can input with your
>> keyboard: " ", ..., - etc.) in Polish translations for years. This is
>> actually incorrect, and for some time now I use proper Unicode
>> characters that the language's rules dictate: „ ”, …, — etc.
>>
>> It is slightly more work for me, sure, but as HIG puts it, it
>> drastically improves the impression given by your applications. I
>> believe some copy and pasting is worth the effort. Here is some info
>> on other ways to input Unicode:
>>
>>
>> https://en.wikipedia.org/wiki/Unicode_input#In_X11_.28Linux_and_other_Unix_variants.29
>>
>> Naturally, every language has different typography rules. I encourage
>> you to look into your language's and consider the change.
>>
>> As a final note, I don't believe there are any technical reasons to
>> avoid Unicode these days, so you shouldn't worry about that. If an app
>> crashes because of UTF-8, then it is a bug that needs to be reported
>> and fixed.
>>
>> Best regards,
>>
>> --
>> Piotr Drąg
>> https://piotrdrag.fedorapeople.org
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
>
> It would be nice to have a script with regexp that could compare msgstr and
> msgid in a PO file, and report strings that are not in compliance with
> GNOME's HIG typography.  I don't have such scripting skill, but if someone
> has it, please consider do it.
>
> Regards,
> Rafael Fontenelle

It is easy to recognize when the English string contains something,
and the translated string does not (e.g. to find a unicode ellipsis
that was translated to an ASCII ellipsis).  But if the English string
uses ASCII, it is not always easy.  For example recognizing exactly
when the en-dash could or should be used instead of an ASCII hyphen.

It is probably a good assumption that any sequence of exactly three
dots should be a unicode ellipsis, no matter the context, but that's
the only trivial case.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Unicode typography in translations

[Ask Hjorth Larsen]

Thanks for checking! The only use case I know about is one of our more
stubborn translators, but he is not active in GNOME anyway...

I guess all relevant distributions use utf8 at least for western languages.

Best regards
Ask

El 14 nov. 2016 19:22, "Piotr Drąg" <piotrd...@gmail.com> escribió:

2016-11-14 18:49 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
> Thanks for all the useful info.  I am very much in favour of using
> unicode as much as possible.  But what happens if someone uses a
> different locale encoding?  For example Danish is typically used with
> UTF8 (LANGUAGE=da_DK.UTF-8), but can also be used with ISO-8859-1.
> ISO-8859-1 does not have the ellipsis.  Will it work anyway, provided
> the po-file specifies UTF-8 as its own encoding?
>

I did a quick test with gedit and totem, which da.po files already
have a Unicode ellipsis and quotation marks, respectively, and they
worked fine with LANG=da_DK.iso-8859-1. I can't guarantee it working
100% of the time (I don't know how the internals work here), but I do
think we are safe in this case.

Besides, I can't imagine why you would need to run GNOME on anything
other than UTF-8. I'd be interested to learn about any use cases,
though.

Best regards,

--
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Unicode typography in translations

[Ask Hjorth Larsen]

Hi

Thanks for all the useful info.  I am very much in favour of using
unicode as much as possible.  But what happens if someone uses a
different locale encoding?  For example Danish is typically used with
UTF8 (LANGUAGE=da_DK.UTF-8), but can also be used with ISO-8859-1.
ISO-8859-1 does not have the ellipsis.  Will it work anyway, provided
the po-file specifies UTF-8 as its own encoding?

Best regards
Ask

2016-11-14 16:52 GMT+01:00 Alexandre Franke :
> On Mon, Nov 14, 2016 at 3:31 PM, Piotr Drąg  wrote:
>> Hello translators,
>
> Hey,
>
>> As a final note, I don't believe there are any technical reasons to
>> avoid Unicode these days,
>
> … including for terminal output. There's no reason to refrain from
> making this look nice as well.
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Strange LINGUAS in GIMP quick reference makefile

[Ask Hjorth Larsen]

Hi gimp documentation team

I was in the process of updating the Danish translation of the quick reference.

The Makefile.am defines ALL_LINGUAS and QUICKREFERENCE_ALL_LINGUAS.

Neither variable is completely consistent with the set of existing
translations: Each is missing some languages, and also the variables
contain nl for which there are no translations.

By divine inspiration I assume that both variables really should
contain all the languages.  This patch will update the two variables
to include all languages for which languages exist:

  http://dcwww.camd.dtu.dk/~askhl/files/gimp-quickref-makefile.diff

Is that correct and good?

Personally I could add 'da' and commit that, but that would not fix
the other languages, and strictly I am not sure whether to add 'da' in
one or both.  So what should be done?

Best regards
Ask

2016-10-03 10:58 GMT+02:00 Ask Hjorth Larsen <asklar...@gmail.com>:
> Hello
>
> In the GIMP quick reference, the Makefile.am contains:
>
> ALL_LINGUAS ?= de el en es fr it ja ko nl nn ru sl sv zh_CN
> QUICKREFERENCE_ALL_LINGUAS ?= ca de el en fi fr it ja ko pl ru sv zh_CN
> QUICKREFERENCE_LINGUAS = $(filter $(ALL_LINGUAS), 
> $(QUICKREFERENCE_ALL_LINGUAS))
>
> I am not really an expert in make, and I would like to add Danish,
> 'da'.  To which of the two lists should 'da' be added, or should it be
> added to both?  And why?
>
> I notice that most languages are listed in both, but ca is only in the
> second, and es is only in the first.  Might this be an error?
>
> Best regards
> Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Strange LINGUAS in GIMP quick reference makefile

[Ask Hjorth Larsen]

Hello

In the GIMP quick reference, the Makefile.am contains:

ALL_LINGUAS ?= de el en es fr it ja ko nl nn ru sl sv zh_CN
QUICKREFERENCE_ALL_LINGUAS ?= ca de el en fi fr it ja ko pl ru sv zh_CN
QUICKREFERENCE_LINGUAS = $(filter $(ALL_LINGUAS), $(QUICKREFERENCE_ALL_LINGUAS))

I am not really an expert in make, and I would like to add Danish,
'da'.  To which of the two lists should 'da' be added, or should it be
added to both?  And why?

I notice that most languages are listed in both, but ca is only in the
second, and es is only in the first.  Might this be an error?

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: [Shotwell] Mass-replacing "..." with …

[Ask Hjorth Larsen]

Hi!

Someone can correct me if I am wrong, but I think the general idea is
never change the po files if you are not a translator, because once in
a while there will be something funny you didn't think of.

Maybe a translator/coordinator is merging something and looking at
diffs, and suddenly there are some changes that cannot be accounted
for - or something.

Also the translators are used to this happening all the time in
Evolution anyway :)

Best regards
Ask

2016-09-29 13:15 GMT+02:00 Jens Georg :
> Hi,
>
> I'm going to mass-replace three dots in strings with the three-dots-
> unicode character - should I adapt all the po files as well?
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: date in friulian

[Ask Hjorth Larsen]

Hi Fabio (re-added i18n, please reply to lits)

Still, it's an irregularity where the text surrounding a number
depends on the number.  This exists in gettext only as the standard
plural form feature.  Fixing it would require multiple such
mechanisms: One for singular/plural, one for dates, one for ordinals,
...

It is not straightforward and would have to be added to gettext, and
would propagate to GNOME and other projects in a matter of years - as
far as I can tell.

Best regards
Ask

2016-06-27 14:04 GMT+02:00 Fabio Tomat <f.t.pub...@gmail.com>:
> In friulian only the date needs this. Ordinals and cardinals numbers are just 
> like other languages.
> So there are 1,2,3,4... And 1st,2nd,3rd...
> But when we talk about dates the first day of the month is "at the first of 
> june..." then we have  "at the 2 of..."
>
> Il lun giu 27 11:29:00 2016 GMT+0200, Ask Hjorth Larsen scrive:
>> But this is more complicated because there is only one plural mechanism,
>> and even English needs a separate mechanism to write things like 1st, 2nd,
>> 3rd and 4th.
>>
>> El 27/06/2016 07:14, "Rafael Fontenelle" <rffontene...@gmail.com> escribió:
>>
>> >
>> > 2016-06-26 2:50 GMT-03:00 Fabio Tomat <f.t.pub...@gmail.com>:
>> >
>> >> Greetings community,
>> >> with gnome 3.20 I modified the dates in gnome as best as I could, but the
>> >> right form of the date is this:
>> >>
>> >> al 1ⁿ di jugn dal 2016  literally translated:  at the(singular) 1ˢᵗ
>> >> of June of the 2016
>> >> ai 25 di jugn dal 2016 literally translated:  at the(plural) 25 of
>> >> June of the 2016
>> >>
>> >> I don't know how to implement this.
>> >> the big problem (in the translated software) is specify if it's the first
>> >> day of the month or one of the remaining days.
>> >>
>> >> Can someone help me resolve this problem, what should I do?
>> >>
>> >> ___
>> >> gnome-i18n mailing list
>> >> gnome-i18n@gnome.org
>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> >>
>> >>
>> > Hi there.
>> >
>> > I don't think 'date' support formatting date output with a superscript
>> > character (or something like that) to denote first day of month. At least
>> > I've got no success with 'date --date 2016-06-01 +%e' or 'date --date
>> > 2016-06-01 +%d'
>> >
>> > I believe your question is typically related to Gettext's Plural-Forms, as
>> > you have one form in singular and another in plural.  My suggestion is to
>> > file a bug report to the proper module (gnome-shell?) to support such date
>> > format.
>> >
>> > Rafael Fontenelle
>> >
>> >
>> > ___
>> > gnome-i18n mailing list
>> > gnome-i18n@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> >
>> >
>>
>
> --
> Inviato dal mio Jolla
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: date in friulian

[Ask Hjorth Larsen]

But this is more complicated because there is only one plural mechanism,
and even English needs a separate mechanism to write things like 1st, 2nd,
3rd and 4th.

El 27/06/2016 07:14, "Rafael Fontenelle"  escribió:

>
> 2016-06-26 2:50 GMT-03:00 Fabio Tomat :
>
>> Greetings community,
>> with gnome 3.20 I modified the dates in gnome as best as I could, but the
>> right form of the date is this:
>>
>> al 1ⁿ di jugn dal 2016  literally translated:  at the(singular) 1ˢᵗ
>> of June of the 2016
>> ai 25 di jugn dal 2016 literally translated:  at the(plural) 25 of
>> June of the 2016
>>
>> I don't know how to implement this.
>> the big problem (in the translated software) is specify if it's the first
>> day of the month or one of the remaining days.
>>
>> Can someone help me resolve this problem, what should I do?
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>>
> Hi there.
>
> I don't think 'date' support formatting date output with a superscript
> character (or something like that) to denote first day of month. At least
> I've got no success with 'date --date 2016-06-01 +%e' or 'date --date
> 2016-06-01 +%d'
>
> I believe your question is typically related to Gettext's Plural-Forms, as
> you have one form in singular and another in plural.  My suggestion is to
> file a bug report to the proper module (gnome-shell?) to support such date
> format.
>
> Rafael Fontenelle
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: date in friulian

[Ask Hjorth Larsen]

2016-06-26 17:00 GMT+02:00 Fabio Tomat <f.t.pub...@gmail.com>:
> Like in gnome-shell dateMenu.js :73
> %B %e %Y

(Re-added gnome-i18n)

I don't know.  Maybe someone else has an idea, but I think strftime
quite lacks the flexibility for this.

Best regards
Ask

>
> Il dom giu 26 14:59:54 2016 GMT+0200, Ask Hjorth Larsen scrive:
>> Hi
>>
>> What are the full strings in English, or where in GNOME do you see those 
>> dates?
>>
>> Best regards
>> Ask
>>
>> 2016-06-26 7:50 GMT+02:00 Fabio Tomat <f.t.pub...@gmail.com>:
>> > Greetings community,
>> > with gnome 3.20 I modified the dates in gnome as best as I could, but the
>> > right form of the date is this:
>> >
>> > al 1ⁿ di jugn dal 2016  literally translated:  at the(singular) 1ˢᵗ of
>> > June of the 2016
>> > ai 25 di jugn dal 2016 literally translated:  at the(plural) 25 of June
>> > of the 2016
>> >
>> > I don't know how to implement this.
>> > the big problem (in the translated software) is specify if it's the first
>> > day of the month or one of the remaining days.
>> >
>> > Can someone help me resolve this problem, what should I do?
>> >
>> > ___
>> > gnome-i18n mailing list
>> > gnome-i18n@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> >
>>
>
> --
> Inviato dal mio Jolla
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: date in friulian

[Ask Hjorth Larsen]

Hi

What are the full strings in English, or where in GNOME do you see those dates?

Best regards
Ask

2016-06-26 7:50 GMT+02:00 Fabio Tomat :
> Greetings community,
> with gnome 3.20 I modified the dates in gnome as best as I could, but the
> right form of the date is this:
>
> al 1ⁿ di jugn dal 2016  literally translated:  at the(singular) 1ˢᵗ of
> June of the 2016
> ai 25 di jugn dal 2016 literally translated:  at the(plural) 25 of June
> of the 2016
>
> I don't know how to implement this.
> the big problem (in the translated software) is specify if it's the first
> day of the month or one of the remaining days.
>
> Can someone help me resolve this problem, what should I do?
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fixes needed for Geary search translations

[Ask Hjorth Larsen]

You can also add an msgctxt to distinguish them. This makes them fuzzy.

Best regards
Ask
El 02/06/2016 13:13, "Michael Gratton" <m...@vee.net> escribió:

> On Wed, Jun 1, 2016 at 4:51 PM, Baurzhan Muftakhidinov <
> baurthefi...@gmail.com> wrote:
>
>> Mark those messages as fuzzy, and then ask translators to revisit them,
>>
>
> Okay, thanks. So I assume the best way to do that is to simply add a "#,
> fuzzy" to the problematic lines manually and commit them to the git repo,
> so they show up as that on l10n.gnome.org?
>
> On Wed, Jun 1, 2016 at 8:51 PM, Ask Hjorth Larsen <asklar...@gmail.com>
> wrote:
>
>> To fix the bug, validate the translated string and use the English one if
>> necessary.
>>
>> I think this should always be done when translations have the potential
>> to crash the application, particularly in complex cases like this.
>>
>
> Yep, I agree. That's exactly what I ended up doing.
>
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ <http://mjog.vee.net/>
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fixes needed for Geary search translations

[Ask Hjorth Larsen]

Hello

To fix the bug, validate the translated string and use the English one if
necessary.

I think this should always be done when translations have the potential to
crash the application, particularly in complex cases like this.

Best regards
Ask
El 01/06/2016 08:52, "Baurzhan Muftakhidinov" 
escribió:

> Hi,
>
> Mark those messages as fuzzy, and then ask translators to revisit them,
>
> Regards.
>
> On Wed, Jun 1, 2016 at 11:47 AM, Michael Gratton  wrote:
> >
> > Hi gnome-i18n,
> >
> > Recently in Geary a search feature was added where people could write a
> > searches such as "is:unread" and have it find all unread messages, also
> > "is:read" and "is:starred". This is implemented by parsing the string
> > separately, i.e. "is:read" is parsed as two separate strings, "is" and
> > "read". Obviously these strings were marked for translation in the code
> so
> > people can use their preferred language, but unfortunately we did not add
> > any comments about the requirements for these (they should ideally be
> short,
> > and must be a single word, or use '_' or '-' to separate words) and so a
> > number were translated as plain phrases instead.
> >
> > I have gone back and added comments for each string so it is hopefully
> more
> > clear what the translation requirements are, but what's the best
> approach to
> > get these problematic strings fixed? Should I replace them with empty
> > strings in the PO files in the git repo so they appear untranslated or
> > should I just ask the translation teams to revisit them?
> >
> > The strings affected are those from both the master and geary-0.11
> branches,
> > in the UI source file "imap-db-account.vala" and ideally should also be
> > translated in the User Guide file "search.page" so that people know what
> the
> > correct syntax is.
> >
> > Since this is related to a crasher bug, I'd like to release 0.11.1
> sometime
> > next week, so it would be great to have the geary-0.11 branch updated
> before
> > then at least.
> >
> > //Mike
> >
> > --
> > ⊨ Michael Gratton, Percept Wrangler.
> > ⚙ 
> >
> >
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: translation on GNOME infrastructure

[Ask Hjorth Larsen]

Committed.

I guess these will always need to be committed manually since they are
just written once for every release, and always must be added to
LINGUAS for that release.

(re-added i18n list.  Please send this kind of mail to the i18n list
since I am not always around, and also the noise might perturb someone
else to improve damned lies :))

Best regards
Ask

2016-03-29 13:01 GMT+02:00 Fabio Tomat <f.t.pub...@gmail.com>:
> Hi, I'm still facing the same issue with Video Subtitles for GNOME's videos
> • GNOME 3.20 Release Video
>
> sorry for these problems but I thought that it should work now...
>
> Thanks for your time and your patience
>
> 2016-03-27 23:32 GMT+02:00 Fabio Tomat <f.t.pub...@gmail.com>:
>>
>> Thank you so much :)
>>
>> Il ven mar 25 15:09:13 2016 GMT+0100, Ask Hjorth Larsen scrive:
>> > (Re-added list to CC)
>> >
>> > Committed:
>> >
>> >
>> > https://git.gnome.org/browse/video-subtitles/commit/?id=e8835237300f8188380a851325b626b5df3a
>> >
>> > Best regards
>> > Ask
>> >
>> > 2016-03-25 7:33 GMT+01:00 Fabio Tomat <f.t.pub...@gmail.com>:
>> > > Thank you, here is the translation.
>> > >
>> > > 2016-03-25 0:14 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>> > >>
>> > >> (The reason is that the first commit for each module in a given
>> > >> language requires modifying the list of languages, which I guess it
>> > >> not yet supported by damned lies.)
>> > >>
>> > >> 2016-03-25 0:13 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>> > >> > Hi Fabio
>> > >> >
>> > >> > If you send the po-file, I (or someone else who is faster) can
>> > >> > probably commit it.  Once committed, further translations can be
>> > >> > done
>> > >> > via damned lies.
>> > >> >
>> > >> > Best regards
>> > >> > Ask
>> > >> >
>> > >> > 2016-03-24 23:23 GMT+01:00 Fabio Tomat <f.t.pub...@gmail.com>:
>> > >> >> Hi, I'm the coordinator of Friulian language, I translated "Video
>> > >> >> Subtitles
>> > >> >> for GNOME's videos • Documentation Video" to my language but it
>> > >> >> seems I
>> > >> >> cannot submit my translation. This is what Damned Lies replied:
>> > >> >> An error occurred during applying your action: The commit failed.
>> > >> >> The
>> > >> >> error
>> > >> >> was: '[Errno 1] remote: translations user cannot modify
>> > >> >> 'video-subtitles/documentation-video/po/LINGUAS' To
>> > >> >> ssh://git.gnome.org/git/video-subtitles ! [remote rejected] master
>> > >> >> ->
>> > >> >> master
>> > >> >> (pre-receive hook declined) error: failed to push some refs to
>> > >> >> 'ssh://git.gnome.org/git/video-subtitles' '
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> ___
>> > >> >> gnome-i18n mailing list
>> > >> >> gnome-i18n@gnome.org
>> > >> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> > >> >>
>> > >
>> > >
>> >
>>
>> --
>> Inviato dal mio Jolla
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: translation on GNOME infrastructure

[Ask Hjorth Larsen]

(Re-added list to CC)

Committed:

  
https://git.gnome.org/browse/video-subtitles/commit/?id=e8835237300f8188380a851325b626b5df3a

Best regards
Ask

2016-03-25 7:33 GMT+01:00 Fabio Tomat <f.t.pub...@gmail.com>:
> Thank you, here is the translation.
>
> 2016-03-25 0:14 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>>
>> (The reason is that the first commit for each module in a given
>> language requires modifying the list of languages, which I guess it
>> not yet supported by damned lies.)
>>
>> 2016-03-25 0:13 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
>> > Hi Fabio
>> >
>> > If you send the po-file, I (or someone else who is faster) can
>> > probably commit it.  Once committed, further translations can be done
>> > via damned lies.
>> >
>> > Best regards
>> > Ask
>> >
>> > 2016-03-24 23:23 GMT+01:00 Fabio Tomat <f.t.pub...@gmail.com>:
>> >> Hi, I'm the coordinator of Friulian language, I translated "Video
>> >> Subtitles
>> >> for GNOME's videos • Documentation Video" to my language but it seems I
>> >> cannot submit my translation. This is what Damned Lies replied:
>> >> An error occurred during applying your action: The commit failed. The
>> >> error
>> >> was: '[Errno 1] remote: translations user cannot modify
>> >> 'video-subtitles/documentation-video/po/LINGUAS' To
>> >> ssh://git.gnome.org/git/video-subtitles ! [remote rejected] master ->
>> >> master
>> >> (pre-receive hook declined) error: failed to push some refs to
>> >> 'ssh://git.gnome.org/git/video-subtitles' '
>> >>
>> >>
>> >>
>> >> ___
>> >> gnome-i18n mailing list
>> >> gnome-i18n@gnome.org
>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> >>
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: translation on GNOME infrastructure

[Ask Hjorth Larsen]

(The reason is that the first commit for each module in a given
language requires modifying the list of languages, which I guess it
not yet supported by damned lies.)

2016-03-25 0:13 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
> Hi Fabio
>
> If you send the po-file, I (or someone else who is faster) can
> probably commit it.  Once committed, further translations can be done
> via damned lies.
>
> Best regards
> Ask
>
> 2016-03-24 23:23 GMT+01:00 Fabio Tomat <f.t.pub...@gmail.com>:
>> Hi, I'm the coordinator of Friulian language, I translated "Video Subtitles
>> for GNOME's videos • Documentation Video" to my language but it seems I
>> cannot submit my translation. This is what Damned Lies replied:
>> An error occurred during applying your action: The commit failed. The error
>> was: '[Errno 1] remote: translations user cannot modify
>> 'video-subtitles/documentation-video/po/LINGUAS' To
>> ssh://git.gnome.org/git/video-subtitles ! [remote rejected] master -> master
>> (pre-receive hook declined) error: failed to push some refs to
>> 'ssh://git.gnome.org/git/video-subtitles' '
>>
>>
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: translation on GNOME infrastructure

[Ask Hjorth Larsen]

Hi Fabio

If you send the po-file, I (or someone else who is faster) can
probably commit it.  Once committed, further translations can be done
via damned lies.

Best regards
Ask

2016-03-24 23:23 GMT+01:00 Fabio Tomat :
> Hi, I'm the coordinator of Friulian language, I translated "Video Subtitles
> for GNOME's videos • Documentation Video" to my language but it seems I
> cannot submit my translation. This is what Damned Lies replied:
> An error occurred during applying your action: The commit failed. The error
> was: '[Errno 1] remote: translations user cannot modify
> 'video-subtitles/documentation-video/po/LINGUAS' To
> ssh://git.gnome.org/git/video-subtitles ! [remote rejected] master -> master
> (pre-receive hook declined) error: failed to push some refs to
> 'ssh://git.gnome.org/git/video-subtitles' '
>
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problem to commit translation for Builder

[Ask Hjorth Larsen]

Hello Enrico

Can you commit to other repositories?  What is the output of git remote -v?

Best regards
Ask

2016-03-18 23:50 GMT+01:00 Enrico :
> Hello folks,
>
> While trying to commit Brazilian Portuguese translation for Builderś help
> (Master branch), I received the following message that prevented me to
> continue the action:
>
> "~/Gnome/gnome-builder/help/pt_BR> git push
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists."
>
>
> Note: I was on the
>
> Please, may someone clarify if I dont have sufficient privilleges to commit
> there?
>
> Thanks in advance, Enrico
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: committing to gimp-help

[Ask Hjorth Larsen]

(Please disregard; I had cloned in a way that gave insufficient
permissions, so it was just the authentication failing.

Best regards
Ask)

2016-03-05 16:22 GMT+01:00 Ask Hjorth Larsen <asklar...@gmail.com>:
> Hi
>
> I would like to commit a number of translations to GIMP help.
>
> Clone and pull from git://git.gnome.org/gimp-help-2 works without
> trouble.  However on attempting to push, it says "fatal: Could not
> read from remote repository."
>
> I could understand if it cannot *write* to it, but reading was
> obviously not a problem just before.
>
> (We are talking about a case which is not supported by damned lies
> because the file was previously untranslated.)
>
> Does anyone know if, say, the procedure is different?
>
> Best regards
> Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

committing to gimp-help

[Ask Hjorth Larsen]

Hi

I would like to commit a number of translations to GIMP help.

Clone and pull from git://git.gnome.org/gimp-help-2 works without
trouble.  However on attempting to push, it says "fatal: Could not
read from remote repository."

I could understand if it cannot *write* to it, but reading was
obviously not a problem just before.

(We are talking about a case which is not supported by damned lies
because the file was previously untranslated.)

Does anyone know if, say, the procedure is different?

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Import problem - Spanish (es) - orca in gnome-orca trunk

[Ask Hjorth Larsen]

Hi

I think Daniel was referring to the files in GNOME being accepted in
GNOME but not necessarily in Launchpad due to different rules.  But
this specific file has real syntax errors and would not be accepted
anywhere:  Two lines that were supposed to be part of a comment are
not.  Probably some non-syntax-aware editor decided to insert line
breaks.

Best regards
Ask

2016-02-17 15:45 GMT+01:00 Joanmarie Diggs :
> Hi Rafael (and Daniel).
>
> For whatever it may be worth, and contrary to what the automated email
> suggests, *I* didn't upload any files. Someone else apparently set
> something up and Launchpad sends me the notifications. Yay technology.
> ;) If I can just ignore this notification as a non-problem, great.
>
> That said: Rafael points out syntax problems; I am not a translator.
> Daniel, what say you?
>
> --joanie
>
> On 02/17/2016 09:21 AM, Rafael Fontenelle wrote:
>> Joanmarie,
>>
>> The file you uploaded to Launchpad has two syntax problemas:
>> 1- Line 13, ", 2015."
>> 2- Line 16, ", 2016"
>>
>> Just move them up, appending to the previous lines (12 and 15) and this
>> problem is fixed.
>>
>> For your information, run "msgfmt -cvo /dev/null .po"  to get
>> detailed information of statistics (translated, fuzzy, not translated)
>> and syntax errors in which line.
>>
>> Cheers,
>> Rafael Fontenelle
>>
>>
>> 2016-02-17 12:03 GMT-02:00 Joanmarie Diggs > >:
>>
>> Hey all.
>>
>> I was planning to do the Orca release this morning (yeah, I know it's
>> late, sorry!!). But I received this automated notification. Is this
>> something we can fix prior to the release?
>>
>> --joanie
>>
>>  Forwarded Message 
>> Subject: Import problem - Spanish (es) - orca in gnome-orca trunk
>> Date: Wed, 17 Feb 2016 07:13:27 -
>> From: nore...@launchpad.net 
>> Reply-To: nore...@launchpad.net 
>> To: jdi...@igalia.com 
>>
>> Hello Joanmarie,
>>
>> On 2016-02-16 23:20z (7 hours 52 minutes ago), you uploaded a file with
>> Spanish (es) translations for orca in gnome-orca trunk to Launchpad.
>>
>> We were unable to import the file because of errors in its format:
>>
>> Line 13: Invalid content: u', 2015.'
>>
>> If you use gettext, you can check your file for correct formatting with
>> the 'msgfmt -c' command. Please fix any errors raised by msgfmt and
>> upload the file again. If you check the file and you don't find any
>> error in it, please look for an answer or file a question at
>> https://answers.launchpad.net/rosetta/
>>
>> For your convenience, you can get the file you uploaded at:
>> http://launchpadlibrarian.net/239473636/es.po
>>
>> Thank you,
>>
>> The Launchpad team
>>
>>
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org 
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Committing from damned lies

[Ask Hjorth Larsen]

Dear all

When committing a translation through the web interface on damned
lies, it certainly committed to the active branch (either master or
gnome-3-18 in the case of the current release cycle).  In many cases
it is necessary to push the changes to both master and gnome-3-18 to
ensure that the strings are applied appropriately in both places.
Does the web interface ensure that the strings appear both in master
and gnome-3-18?

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: 24-hour or 12-our clock and %p

[Ask Hjorth Larsen]

Well, I think the best option is number 2.  It produces things that
are correct in Danish (05:00 and 17:00 can both be 5 o'clock in
normal non-computer speech) which, although quite useless due to the
ambiguity, is not a problem because no Danish user should/would be
using 12-hour clock setting anyway.

In the end the problem is that those strings have no reason to exist
in the language and therefore it's not well defined how they should be
translated.  Instead of making things easier, it causes headaches like
zero divided by zero.  I conclude that it doesn't matter much, and
rule that the Danish convention in GNOME from now on is option 2 :)

Thank you very much!

Best regards
Ask

2015-03-02 16:48 GMT+01:00 Rafael Ferreira rafael.f...@gmail.com:
 2015-03-02 8:49 GMT-03:00 Alexandre Franke alexandre.fra...@gmail.com:
 On Mon, Mar 2, 2015 at 12:08 PM,  k...@keldix.com wrote:
 For Danish, ther is no 12-hour format. The best is then to leave the 
 specification blank.

 This is a terrible suggestion. You should never leave a string blank.
 If you intend to use the same as the original version, you should copy
 it.

 Alternatively you can make the 12-hour format the same as the 24-hour 
 format.

 If by that you mean using %H, then again this is a terrible suggestion
 (see earlier mail in this thread, this will appear as a bug to the
 user).



 It looks to me that both 1 and 3 will represent a bug in Danish
 localization. Forcing 24-hour (option 1) will show a weird 12-hour
 button that returns 24-hour, while using 12-hour (option 3) will show
 a 12-hour clock that doesn't exists in Danish language and therefore
 is weird.

 How about requesting the developer to hide the 12-hour option when
 language is Danish?
 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: 24-hour or 12-our clock and %p

[Ask Hjorth Larsen]

Hello Hannie

I should clarify: This is when the translator comment says 12-hour
clock format and there's another string called 24-hour clock
format.  I have to translate both, and I leave the 24-hour clock
format unchanged.  The locale settings should choose the 24-hour clock
format presumably.  But how do I translate the 12-hour one, in case
someone ends up actually seeing that?  There is no correct unambiguous
way to translate it and still respect the translator comment.  So do I
translate it to 24-hour clock (disrespecting comment), 12-hour+am/pm
(incorrect in many countries) or 12-hour (ambiguous)?  Perhaps it
doesn't matter at all, but since I spend time thinking about it every
time, maybe someone had a rule.  Oh well.

I guess I will go for the ambiguous translation in the end, in spite
of the fact that 12-hour clocks on computers are pretty useless :)

Best regards
Ask


2015-03-01 10:47 GMT+01:00 Hannie Dumoleyn lafeber-dumole...@zonnet.nl:
 We, the Dutch translation team, use the 24-hour clock most of the time,
 since this is custom in our country.
 Hannie

 Op 28-02-15 om 20:05 schreef Ask Hjorth Larsen:

 Hello

 In many languages including Danish, am and pm (%p in strftime)
 do not exist.  When using the 12-hour clock one would simply say e.g.
 11:32 which is of course ambiguous.  On a computer one would use the
 24-hour clock to simply avoid this ambiguity.

 However we still have to provide a translation for strings like %l:%M
 %p.  So what is the most correct translation?

   1) Force the user to use 24-hour clock by simply translating it to
 %H:%M, or
   2) use the imprecise %l:%M, or
   3) retain the alien %l:%M %p?

 The user should probably not be using 12-hour clock in the first
 place, and so we would presumably rely on the locale settings already
 making it so that the correct code gets called.  I would therefore
 guess that option 3) is better.  In some cases, though, the idea might
 be that the translator chooses the format by means of the translation,
 and so it would be completely pointless not to use the most natural,
 24-hour string.  Are there any rules or specifications for this?

 Best regards
 Ask
 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n


 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

24-hour or 12-our clock and %p

[Ask Hjorth Larsen]

Hello

In many languages including Danish, am and pm (%p in strftime)
do not exist.  When using the 12-hour clock one would simply say e.g.
11:32 which is of course ambiguous.  On a computer one would use the
24-hour clock to simply avoid this ambiguity.

However we still have to provide a translation for strings like %l:%M
%p.  So what is the most correct translation?

 1) Force the user to use 24-hour clock by simply translating it to %H:%M, or
 2) use the imprecise %l:%M, or
 3) retain the alien %l:%M %p?

The user should probably not be using 12-hour clock in the first
place, and so we would presumably rely on the locale settings already
making it so that the correct code gets called.  I would therefore
guess that option 3) is better.  In some cases, though, the idea might
be that the translator chooses the format by means of the translation,
and so it would be completely pointless not to use the most natural,
24-hour string.  Are there any rules or specifications for this?

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: GTXML report: errors in documentation

[Ask Hjorth Larsen]

Hello

The mismatched tag and not well-formed are generally real errors.
I still don't have a way of telling which constructs are legal in the
case of undefined entity which may therefore (and frequently does)
give false positives e.g. in Japanese and Brazilian-Portuguese.  If we
had a way to know which constructs (mdash;, amp; and all that) are
legal, then this would be easier.

Should we disable the check for undefined entity?  Some errors would
go undetected, but people might pay more attention since they will all
be real errors.

Best regards
Ask

2014-09-20 19:26 GMT+02:00 Daniel Mustieles García daniel.mustie...@gmail.com:
 And now with the report attatched

 Sorry...

 2014-09-20 19:21 GMT+02:00 Daniel Mustieles García
 daniel.mustie...@gmail.com:

 Here is the las report, and these are the affected languages:

 de
 el
 fr
 ja
 pt_BR
 ro
 sl

 Note that this report also contains errors in non-core modules, which are
 not under the release cycle, so no need to fix them ASAP (but highly
 recommended).

 Cheers!

 2014-09-18 23:24 GMT+02:00 Christian Kirbach
 christian.kirb...@gmail.com:

 Am Mittwoch, den 10.09.2014, 12:51 +0200 schrieb Daniel Mustieles
 García:
  Hi all,
 
  As usual, I've created a report (attatched) with the languages
  containing typos or errors in tags in documentation files. Here is the
  list of the affected languages:
 
  cs
  de

 de should be fixed. Thank you for your efforts.

 I'd say it would make sense if you run the report again, if possible for
 you, so people can fix some more issues on the weekend for the 3.14
 release next week.


 --
 Christian Kirbach christian.kirb...@gmail.com




 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Committing translations

[Ask Hjorth Larsen]

Hello

Kenneth, our previous coordinator, has argued very convincingly that
working over the mailing list is more efficient than using damned
lies.  Amongst other things this is because we always proofread a
specially generated podiff.  It also seems to me that the damned lies
workflow involves the reviewer correcting the po-file.  In our group
the reviewer writes comments in the podiff to the translator who then
learns something and edits the po-file.  A minor issue perhaps, but
it's not so smooth with damned lies, and there are a few other reasons
as well.

So I would be quite interested in a git account.  Could this be arranged please?

Best regards
Ask

2014-09-12 0:30 GMT+02:00 Ask Hjorth Larsen asklar...@gmail.com:
 Hello Alexandre

 2014-09-12 0:15 GMT+02:00 Alexandre Franke alexandre.fra...@gmail.com:
 On Fri, Sep 12, 2014 at 12:02 AM, Ask Hjorth Larsen asklar...@gmail.com 
 wrote:
 Hello translators and other wise people

 Hey Ask!

 I recently became coordinator of the Danish translation team.  I am
 now using damned lies to commit some translations.  It results in a
 bit more clicking than strictly necessary.

 That's because you're doing it wrong. ;-)

 Right :).  Well...


 Basically we use a mailing list to facilitate the proofreading
 process, and our translators eventually send the finished files to our
 mailing list for committing.  What I do then is to go to damned lies,
 remove their reservation, upload the new file, claim that it's ready
 to be committed, and then I commit it.  This does not seem to fit 100%
 the way the system was thought out.  Is it an acceptable way to do
 things?  It is a lot of clicking to circumvent things that are
 obviously meant to be there.

 Acceptable, sure. Best choice? I don't think so.

 While a mailing list can be an okay tool for the job, Damned lies
 really shines in that context and was designed for that workflow. It's
 way better as it allows you to track the exact state of modules. You
 can see what's been translated and not reviewed yet, what's reviewed
 and needs to be pushed to the repos, or what is being left out by
 translators. You can also use the commenting system to have a
 discussion and I think this is better than a thread on a mailing list
 as it keeps the relevant messages grouped together in one place on the
 module page.

 The fact that you can diff between the submitted files and the repos,
 or the automatic merging/updating of files when new strings appear in
 the module, are also killer features that you won't find in a mailing
 list centered workflow.

 I may be forgetting other advantages to using Damned lies, but I hope
 I've made my point with what I already said.

 As an alternative I could use git directly, but I don't have a key
 registered for that.

 Meh. You can do it if you decide to keep using the mailing list, but I
 don't think it's a good idea.

 What do you generally do and think?

 Of course each team is free to work the way they want, but I strongly
 advise you to use Damned lies for the whole process. It will make your
 life way easier, believe me. :-)

 --
 Alexandre Franke

 We translate a lot of different projects through the mailinglist, many
 of which are not on damned lies.  I guess I can ask the others how
 they like to do things.  But since we (ir)regularly get po-files from
 translationproject.org, Launchpad, KDE, transifex and GNOME, it's a
 bit out of the way for us to make exceptions for GNOME.  I do agree
 with you that damned lies is very powerful though.  We'll see...

 Thank you again.

 Best regards
 Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Committing translations

[Ask Hjorth Larsen]

Hello translators and other wise people

I recently became coordinator of the Danish translation team.  I am
now using damned lies to commit some translations.  It results in a
bit more clicking than strictly necessary.

Basically we use a mailing list to facilitate the proofreading
process, and our translators eventually send the finished files to our
mailing list for committing.  What I do then is to go to damned lies,
remove their reservation, upload the new file, claim that it's ready
to be committed, and then I commit it.  This does not seem to fit 100%
the way the system was thought out.  Is it an acceptable way to do
things?  It is a lot of clicking to circumvent things that are
obviously meant to be there.

As an alternative I could use git directly, but I don't have a key
registered for that.

What do you generally do and think?

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Committing translations

[Ask Hjorth Larsen]

Hello Alexandre

2014-09-12 0:15 GMT+02:00 Alexandre Franke alexandre.fra...@gmail.com:
 On Fri, Sep 12, 2014 at 12:02 AM, Ask Hjorth Larsen asklar...@gmail.com 
 wrote:
 Hello translators and other wise people

 Hey Ask!

 I recently became coordinator of the Danish translation team.  I am
 now using damned lies to commit some translations.  It results in a
 bit more clicking than strictly necessary.

 That's because you're doing it wrong. ;-)

Right :).  Well...


 Basically we use a mailing list to facilitate the proofreading
 process, and our translators eventually send the finished files to our
 mailing list for committing.  What I do then is to go to damned lies,
 remove their reservation, upload the new file, claim that it's ready
 to be committed, and then I commit it.  This does not seem to fit 100%
 the way the system was thought out.  Is it an acceptable way to do
 things?  It is a lot of clicking to circumvent things that are
 obviously meant to be there.

 Acceptable, sure. Best choice? I don't think so.

 While a mailing list can be an okay tool for the job, Damned lies
 really shines in that context and was designed for that workflow. It's
 way better as it allows you to track the exact state of modules. You
 can see what's been translated and not reviewed yet, what's reviewed
 and needs to be pushed to the repos, or what is being left out by
 translators. You can also use the commenting system to have a
 discussion and I think this is better than a thread on a mailing list
 as it keeps the relevant messages grouped together in one place on the
 module page.

 The fact that you can diff between the submitted files and the repos,
 or the automatic merging/updating of files when new strings appear in
 the module, are also killer features that you won't find in a mailing
 list centered workflow.

 I may be forgetting other advantages to using Damned lies, but I hope
 I've made my point with what I already said.

 As an alternative I could use git directly, but I don't have a key
 registered for that.

 Meh. You can do it if you decide to keep using the mailing list, but I
 don't think it's a good idea.

 What do you generally do and think?

 Of course each team is free to work the way they want, but I strongly
 advise you to use Damned lies for the whole process. It will make your
 life way easier, believe me. :-)

 --
 Alexandre Franke

We translate a lot of different projects through the mailinglist, many
of which are not on damned lies.  I guess I can ask the others how
they like to do things.  But since we (ir)regularly get po-files from
translationproject.org, Launchpad, KDE, transifex and GNOME, it's a
bit out of the way for us to make exceptions for GNOME.  I do agree
with you that damned lies is very powerful though.  We'll see...

Thank you again.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: New coordinator for the Danish team

[Ask Hjorth Larsen]

Hello Rafael

Thank you!  Looks like I won't need a git account for now.  Perhaps at
some later point.

Best regards
Ask

2014-07-22 21:16 GMT+02:00 Rafael Ferreira rafael.f...@gmail.com:
 Ask,

 Firstly, congratulations and i wish the best of lucks on this new assignment!

 You can read some about team coordinator's responsabilities[1] and
 actions[2], and about the account team[3], to whom you can request
 e.g. GIT access [4]

 [1] https://wiki.gnome.org/TranslationProject/TeamCoordinatorResponsibilities
 [2] https://wiki.gnome.org/TranslationProject/CoordinationActions
 [3] https://wiki.gnome.org/AccountsTeam
 [4] https://wiki.gnome.org/AccountsTeam/NewAccounts

 p.s.: just in case you don't know, you will need GIT access to commit
 newly translated documentations, but UI and already-started
 documentations can be commited from Damned-Lies.

 Cheers,
 Rafael Ferreira

 2014-07-22 15:12 GMT-03:00 Ask Hjorth Larsen asklar...@gmail.com:
 Thank you, Claude.  I am not entirely sure what to do.  I suppose I
 could start coordinating something for one thing. :)

 But also I should be able to commit stuff as well, right?  That means
 someone has to calculate some prime numbers or something like that to
 generate a key of some sort, or am I mistaken?

 Best regards
 Ask

 2014-07-21 10:16 GMT+02:00 Claude Paroz cla...@2xlibre.net:
 Le mardi 15 juillet 2014 à 01:11 +0200, Ask Hjorth Larsen a écrit :
 Dear all

 I confirm that I will be taking over as coordinator of the Danish
 GNOME translation team.  Thank you, Kenneth, for the immense amount of
 work on every GNOME release and the innumerable other projects over
 more than seven years: translations, proofreading, commits, research,
 bug reports, code development, coordination work in general, and last
 but not least all the fun.  And a special thank you for introducing me
 to GNOME l10n in the first place.  Also I have no doubt we will manage
 to find time for many a translation sprint in the future.

 As Kenneth said, please let me know what to do to proceed.

 Hello,

 Change done: https://l10n.gnome.org/teams/da/

 +1 to the thank yous for Kenneth. Much appreciated!

 Claude
 --
 www.2xlibre.net

 2014-07-15 0:24 GMT+02:00 Kenneth Nielsen k.nielse...@gmail.com:
  Hallo everyone
 
  After several years on the post, it is now time for me to pass on the 
  title.
 
  Taking over will be Ask Hjorth Larsen.
 
  Ask has been a very active and skilful translator and proofreader for
  several years now and I know him personally to be a very dedicated 
  person,
  whom I'm sure will do the job very nicely.
 
  Will you help us getting started with the steps needed to make the
  transition.
 
  Thanks in advance.
  Kenneth


 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: New coordinator for the Danish team

[Ask Hjorth Larsen]

Thank you, Claude.  I am not entirely sure what to do.  I suppose I
could start coordinating something for one thing. :)

But also I should be able to commit stuff as well, right?  That means
someone has to calculate some prime numbers or something like that to
generate a key of some sort, or am I mistaken?

Best regards
Ask

2014-07-21 10:16 GMT+02:00 Claude Paroz cla...@2xlibre.net:
 Le mardi 15 juillet 2014 à 01:11 +0200, Ask Hjorth Larsen a écrit :
 Dear all

 I confirm that I will be taking over as coordinator of the Danish
 GNOME translation team.  Thank you, Kenneth, for the immense amount of
 work on every GNOME release and the innumerable other projects over
 more than seven years: translations, proofreading, commits, research,
 bug reports, code development, coordination work in general, and last
 but not least all the fun.  And a special thank you for introducing me
 to GNOME l10n in the first place.  Also I have no doubt we will manage
 to find time for many a translation sprint in the future.

 As Kenneth said, please let me know what to do to proceed.

 Hello,

 Change done: https://l10n.gnome.org/teams/da/

 +1 to the thank yous for Kenneth. Much appreciated!

 Claude
 --
 www.2xlibre.net

 2014-07-15 0:24 GMT+02:00 Kenneth Nielsen k.nielse...@gmail.com:
  Hallo everyone
 
  After several years on the post, it is now time for me to pass on the 
  title.
 
  Taking over will be Ask Hjorth Larsen.
 
  Ask has been a very active and skilful translator and proofreader for
  several years now and I know him personally to be a very dedicated person,
  whom I'm sure will do the job very nicely.
 
  Will you help us getting started with the steps needed to make the
  transition.
 
  Thanks in advance.
  Kenneth


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: New coordinator for the Danish team

[Ask Hjorth Larsen]

Dear all

I confirm that I will be taking over as coordinator of the Danish
GNOME translation team.  Thank you, Kenneth, for the immense amount of
work on every GNOME release and the innumerable other projects over
more than seven years: translations, proofreading, commits, research,
bug reports, code development, coordination work in general, and last
but not least all the fun.  And a special thank you for introducing me
to GNOME l10n in the first place.  Also I have no doubt we will manage
to find time for many a translation sprint in the future.

As Kenneth said, please let me know what to do to proceed.

Best regards
Ask


2014-07-15 0:24 GMT+02:00 Kenneth Nielsen k.nielse...@gmail.com:
 Hallo everyone

 After several years on the post, it is now time for me to pass on the title.

 Taking over will be Ask Hjorth Larsen.

 Ask has been a very active and skilful translator and proofreader for
 several years now and I know him personally to be a very dedicated person,
 whom I'm sure will do the job very nicely.

 Will you help us getting started with the steps needed to make the
 transition.

 Thanks in advance.
 Kenneth
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: gnome-devel-docs on developer.gnome.org

[Ask Hjorth Larsen]

Hello

Daniel: Sorry for the late reply.  gtxml presently assumes that
strings by default should be valid xml, which was not the case in
previous revisions.  This probably explains the difference.  Back in
the days I don't think there were translator_credits strings in the
docs, so this change could be made without getting into trouble -
something which clearly isn't the case anymore.  It's a simple matter
to recognize the translator credits strings though.

So in general: gtxml is not only meant for the GNOME docs, it's
supposed to be a bit more generalist.  An option or mode could be
written (without much trouble at all) specifically for GNOME docs to
weed out known false positives.  If a powerful being confirms that a
gtxml check is desired for the GNOME docs (and by powerful I mean
someone who has the rights/expertise/etc. to get things to run on the
server) then I will be glad to write a special mode.

Regarding the placeholders: I don't know how to completely generally
recognize a placeholder tag.  I.e. whether, upon seeing a tag, it has
to exist in the translation as well or not.  For a placeholder the
answer is yes.  For another tag the answer is typically no.

Best regards
Ask

2014-05-13 11:33 GMT+02:00 Daniel Mustieles García daniel.mustie...@gmail.com:
 As I've commented to Christian Kirbach in private mail, when I generated the
 reports before a new stable release, I didn't get this kind of errors, so
 I'm really confused about what is happening. The only difference I see is
 that I used to generate them under Ubuntu 12, and now I'm using Debian...
 maybe it's due to Python versions? I'm installing a virtual machine to
 investigate it...

 Anyway... simply ignoring the translator-credits line would be enough to
 have good reports. Media links are not used at all in the PO files, so it
 doesn't matter how you translate them; about placeholders, they should
 placed in the right place, as they often indicate the kind of license or the
 name of the program, so they should be, at least, the same in the translated
 and in the original string (but not in the same order).

 Thanks to all of you for your comments (and special thanks to Ask for taking
 care of this :) )

 Cheers!


 2014-05-09 19:44 GMT+02:00 Rūdolfs Mazurs rudolfs.maz...@gmail.com:

 Pk, 2014.05.09. 16:51 +, Rafael Ferreira rakstīja:
  If someone that knows python3 could patch pyg3t to fix this, I think
  it would be a great tool for this XML validation... Someone?

 specifically in translator-credits strings, the e-mail is often put in
 angle brackets, which is not a valid XML.

 If the translator-credits string is parsed with XML, that IS a bug.
 Otherwise just skip the translator-credits string in the xml check.

 --
 Rūdolfs Mazurs rudolfs.maz...@gmail.com

 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n



 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: gnome-devel-docs on developer.gnome.org

[Ask Hjorth Larsen]

Hello everyone

First of all I am very willing to implement a mode in gtxml
specifically for this.

Fixing the translator-credits issue is obviously very easy.

I can make it so that gtxml will only complain about syntax errors,
i.e. strings that are not accepted by the xml parser.  This requires
that all msgids and msgstrs - except the header and translator-credits
- can be assumed to be XML.

The files also contain media links to images/videos with their md5
hashes.  Perhaps a special check should be made for those, since they
are probably not required to be legal XML.  Are there other classes of
strings to be aware of?  Is all this acceptable?  Also, who could
actually approve this and make it run on the server?

Right now gtxml can to various extents be smarter and detect more
errors - e.g. whether unexpected XML tags are used.  But some
translators tend to insert their own little xml things when they want,
which is fine by itself, but can lead to false positives when
attempting to be too smart.

What happens with placeholder tags (such as _:ulink-1, _:ulink-2 and
so on), how bad is it if those are messed up?

Of course the ultimate authority on whether the translations are valid
or not is the software that compiles the documentation.  So another
possible filter would be to actually compile the darn thing as soon as
it gets checked in and use that as a test.

Best regards
Ask

2014-05-09 19:40 GMT+02:00 Daniel Mustieles García daniel.mustie...@gmail.com:
 Pyg3t's maintainer is in Cc (Ask) so maybe he is the best option to fix it
 ;-)

 El 09/05/2014 18:51, Rafael Ferreira rafael.f...@gmail.com escribió:

 No, it is a false positive. My example had only one translator. But here
 is another example, now with two translators in translator-credits:

 $ gtxml ~/Downloads//optimization-guide.master.pt_BR.po
 At line 24: not well-formed (invalid token)
 ---
 #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2
 msgctxt _
 msgid translator-credits
 msgstr 
 Enrico Nicoletto live...@gmail.com, 2012\n
 Rafael Ferreira rafael.f...@gmail.com, 2013


 If someone that knows python3 could patch pyg3t to fix this, I think it
 would be a great tool for this XML validation... Someone?




 2014-05-09 16:40 GMT+00:00 Daniel Mustieles García
 daniel.mustie...@gmail.com:

 Maybe it is because of the newline character? Translator credits should
 be in one line per credit

 El 09/05/2014 18:01, Rafael Ferreira rafael.f...@gmail.com escribió:

 The only false positive I know of gtxml is the 'translator-credits'
 string, returning exit code 1. For instance:

 $ gtxml platform-demos.master.pt_BR.po
 At line 23: not well-formed (invalid token)
 ---
 #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2
 msgctxt _
 msgid translator-credits
 msgstr Rafael Ferreira rafael.f...@gmail.com, 2013




 2014-05-09 15:49 GMT+00:00 Daniel Mustieles García
 daniel.mustie...@gmail.com:

 No AFAIK, but I'm not 100% about it.

 Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this
 question.

 El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com
 escribió:

 On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García
 daniel.mustie...@gmail.com wrote:
  Hi,

 Hi,

  Could we implement a pre-commit hook to check XML syntax with gtxml
  [1]?

 Are there any false positives?

 --
 Alexandre Franke
 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n


 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n




___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Errors in documentation

[Ask Hjorth Larsen]

Hello

Thanks Daniel, ¡muchas gracias como siempre!  And thanks, Piotr.
(Although I swear we were going to do this :))

Best regards
Ask


2014-03-10 15:41 GMT+01:00 Piotr Drąg piotrd...@gmail.com:
 2014-03-07 16:32 GMT+01:00 Daniel Mustieles García 
 daniel.mustie...@gmail.com:
 As usual, I've made a report with some typos or errors in XML tags in
 documentation. I've attatched a file with the typos found, sorted by
 language. Here is the list of the affected languages:


 Thanks for the report! I've fixed tags that weren't fixed yet by others.

 I think your clone of balsa is out of date, so in fact Slovenian has
 no errors. :)

 Best regards,

 --
 Piotr Drąg
 http://raven.fedorapeople.org/
 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Some translation review of strings in GNOME Software

[Ask Hjorth Larsen]

Hello Richard

2013/9/15 Richard Hughes hughsi...@gmail.com:
 On 15 September 2013 16:39, Kenneth Nielsen k.nielse...@gmail.com wrote:
 msgid %s will be removed, and you will have to install it to use it again.
 -- ... to reinstall it ..., maybe?

 I got scolded a few years ago for using re-install, as it's not
 technically a word. I'm open for ideas here.

Oh dear.  But the Oxford English Dictionary says:

reinstall  verb (reinstalls, reinstalling, reinstalled) [with obj.] 1
place or fix (equipment or machinery) in position again.
(etc.)

Even if it hadn't been in the dictionary, it is so commonly used in
computing that I would argue that it exists.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

More on xml errors in documentation

[Ask Hjorth Larsen]

Hello

Below are some error reports for GNOME docs which are considerably
more strict than usual.

I would like to know how useful this kind of report is.  It complains,
aside from the usual syntax errors, about tags it cannot find in the
corresponding msgid.  This will lead to false positives in cases where
the translator chooses to add, say, app.../app to a programme name
when the msgid didn't.  I will appreciate any feedback (this is
ridiculous, everything was totally okay or otherwise).

Here are the reports.  Only some languages with many doc translations
have been included.

http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.de.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.el.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.es.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.fr.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.gl.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.hu.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.pt_BR.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.ru.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.sl.txt
http://www.student.dtu.dk/~ashj/opendir/gtxml.strict.zh_CN.txt

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: keywords in desktop files, again

[Ask Hjorth Larsen]

Thanks, the one in Danish has been corrected :)

2013/3/24 Daniel Mustieles García daniel.mustie...@gmail.com:
 Hi all,

 Here is the report I've generated about the missing «;» in the Keywords
 translated string.

 Translation team coordinator: As this is an important fix we should do
 before the new release, please let me know if you won't be able to fix it,
 so I'll review and fix it for you.

 Best regards


 2013/3/24 Daniel Mustieles García daniel.mustie...@gmail.com

 Hi Ask,

 You can use this script to get all the PO files for the most relevant
 languages. The script also has the ability to get all the language codes
 from DL, sou you can get all the PO files from all the languages.

 Cheers!


 2013/3/23 Ask Hjorth Larsen asklar...@gmail.com

 Hi

 What is the easiest way to download all the translations in all
 languages?

 Regards
 Ask

 2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
  It works great!!
 
  I've detected (and fixed) an error in gnome-control-center. Thanks!!
 
  This weekend ill try to clean the output to be less verbose and I'll
  create
  a report with it. Stay tuned!!
 
  Again, many thanks!
 
 
  2013/3/22 Ask Hjorth Larsen asklar...@gmail.com
 
  It can be used like this:
 
  askhl@mime:~/translate$ find -name *.po | xargs desktopfilecheck.py
  ./gdm-and-friends/gnome-control-center.gnome-3-8.da.po
  ERROR, bad syntax line 6684:
  #. Translators: those are keywords for the wacom tablet control-center
  panel
  #: ../panels/wacom/gnome-wacom-panel.desktop.in.in.h:4
  msgid Tablet;Wacom;Stylus;Eraser;Mouse;
  msgstr Tegneplade;Wacom;Pen;Viskelæder;Mus
 
  Regards
  Ask
 
  2013/3/22 Ask Hjorth Larsen asklar...@gmail.com:
   Hi, here's a script (uses pyg3t):
  
 http://www.student.dtu.dk/~ashj/opendir/desktopfilecheck.py
  
   I'm actually at work at the moment, but someone can run it or I'll
   do
   it tomorrow or so when I have time.
  
   Let me know about any issues or if it needs to check for anything
   else.
  
   Regards
   Ask
  
   2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
   Hi Ask,
  
   The Keywords string just has to end with ; to be ok, no need to
   have
   the
   same number of words
  
   Many thanks fin advance for your script!
  
  
   2013/3/22 Ask Hjorth Larsen asklar...@gmail.com
  
   Hi
  
   Could someone specify how these files *should* be translated?
   Must
   there be the same number of elements in the list?
  
   I suppose the most obvious thing is that it should end with ;.
  
   I'll write a script and check it on all the files, then send a
   complete
   list.
  
   Regards
   Ask
  
   2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
In bash it may be tricky to do this check, but I guess Python
could
help. I
tried to do it in bash and I wasted my time :(
   
   
2013/3/22 Andre Klapper ak...@gmx.net
   
On Fri, 2013-03-22 at 15:46 +0100, Olav Vitters wrote:
 Any idea how that could be implemented? I am willing to make
 it
 happen,
 just don't see how. E.g. figure out exactly which line is the
 Keywords
 line, etc.
   
Grep for a line that starts with
 #: ../
and includes the string
.desktop.in.in.h:
then find the next line that starts with
msgid
and ends with
;
then count the number of ; in that specific line,
compare that number with the next line that starts with
msgstr
and which is not
msgstr 
which would mean not translated yet.
Trigger a warning if the number is not the same.
Or something like that. Cough. Sounds error-prone.
   
andre
--
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
   
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
   
   
   
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
   
  
  
 
 



___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Typos in documentation tags

[Ask Hjorth Larsen]

Hi Gabor

2013/3/24 Gabor Kelemen kelem...@gnome.hu:
 2013-03-24 12:03 keltezéssel, Daniel Mustieles García írta:
 Hi Jiro,

 Here is the script I've used to generate the reports.


 Hi Daniel

 I have tried to run gtxml on a single file I have updated yesterday, but
 I get a UnicodeDecodeError:

 $ gtxml hu/hu.po
 Traceback (most recent call last):
   File /usr/bin/gtxml, line 5, in module
 gtxml.main()
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 160, in main
 for bad_msg, err in gtxml.check_msgs(cat):
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 53, in
 check_msgs
 self.check_msg(msg)
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 46, in
 check_msg
 self.check_string(msgstr)
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 25, in
 check_string
 xmlstring = self._filter(string)
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 21, in
 _filter
 xml = u''.join([u'xml', string.replace(u'\\', u''), u'/xml'])
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 24:
 ordinal not in range(128)

 This is on Ubuntu Precise, with gtxml from the PPA
 https://launchpad.net/~pyg3t-dev-team/+archive/ppa
 and with any documentation po file.

 What else is needed for this to work?

 Thanks in advance
 Gabor Kelemen

I think we have fixed this in trunk, but due to very little time on
our hands we haven't managed a release lately :S

Maybe your system encoding is different than on the systems where we wrote it.

If you send the file I can take a look.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Typos in documentation tags

[Ask Hjorth Larsen]

Hi Gabor

2013/3/24 Ask Hjorth Larsen asklar...@gmail.com:
 Hi Gabor

 2013/3/24 Gabor Kelemen kelem...@gnome.hu:
 2013-03-24 12:03 keltezéssel, Daniel Mustieles García írta:
 Hi Jiro,

 Here is the script I've used to generate the reports.


 Hi Daniel

 I have tried to run gtxml on a single file I have updated yesterday, but
 I get a UnicodeDecodeError:

 $ gtxml hu/hu.po
 Traceback (most recent call last):
   File /usr/bin/gtxml, line 5, in module
 gtxml.main()
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 160, in main
 for bad_msg, err in gtxml.check_msgs(cat):
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 53, in
 check_msgs
 self.check_msg(msg)
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 46, in
 check_msg
 self.check_string(msgstr)
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 25, in
 check_string
 xmlstring = self._filter(string)
   File /usr/lib/python2.7/dist-packages/pyg3t/gtxml.py, line 21, in
 _filter
 xml = u''.join([u'xml', string.replace(u'\\', u''), u'/xml'])
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 24:
 ordinal not in range(128)

 This is on Ubuntu Precise, with gtxml from the PPA
 https://launchpad.net/~pyg3t-dev-team/+archive/ppa
 and with any documentation po file.

 What else is needed for this to work?

 Thanks in advance
 Gabor Kelemen

 I think we have fixed this in trunk, but due to very little time on
 our hands we haven't managed a release lately :S

 Maybe your system encoding is different than on the systems where we wrote it.

 If you send the file I can take a look.

 Regards
 Ask

I just looked at one of the Hungarian files and we must have messed up
a bit in gtxml during the last release.  It's fixed in trunk.  Sorry
for the inconvenience, we'll make a new release as soon as possible.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: keywords in desktop files, again

[Ask Hjorth Larsen]

Hi

What is the easiest way to download all the translations in all languages?

Regards
Ask

2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
 It works great!!

 I've detected (and fixed) an error in gnome-control-center. Thanks!!

 This weekend ill try to clean the output to be less verbose and I'll create
 a report with it. Stay tuned!!

 Again, many thanks!


 2013/3/22 Ask Hjorth Larsen asklar...@gmail.com

 It can be used like this:

 askhl@mime:~/translate$ find -name *.po | xargs desktopfilecheck.py
 ./gdm-and-friends/gnome-control-center.gnome-3-8.da.po
 ERROR, bad syntax line 6684:
 #. Translators: those are keywords for the wacom tablet control-center
 panel
 #: ../panels/wacom/gnome-wacom-panel.desktop.in.in.h:4
 msgid Tablet;Wacom;Stylus;Eraser;Mouse;
 msgstr Tegneplade;Wacom;Pen;Viskelæder;Mus

 Regards
 Ask

 2013/3/22 Ask Hjorth Larsen asklar...@gmail.com:
  Hi, here's a script (uses pyg3t):
 
http://www.student.dtu.dk/~ashj/opendir/desktopfilecheck.py
 
  I'm actually at work at the moment, but someone can run it or I'll do
  it tomorrow or so when I have time.
 
  Let me know about any issues or if it needs to check for anything else.
 
  Regards
  Ask
 
  2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
  Hi Ask,
 
  The Keywords string just has to end with ; to be ok, no need to have
  the
  same number of words
 
  Many thanks fin advance for your script!
 
 
  2013/3/22 Ask Hjorth Larsen asklar...@gmail.com
 
  Hi
 
  Could someone specify how these files *should* be translated?  Must
  there be the same number of elements in the list?
 
  I suppose the most obvious thing is that it should end with ;.
 
  I'll write a script and check it on all the files, then send a
  complete
  list.
 
  Regards
  Ask
 
  2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
   In bash it may be tricky to do this check, but I guess Python could
   help. I
   tried to do it in bash and I wasted my time :(
  
  
   2013/3/22 Andre Klapper ak...@gmx.net
  
   On Fri, 2013-03-22 at 15:46 +0100, Olav Vitters wrote:
Any idea how that could be implemented? I am willing to make it
happen,
just don't see how. E.g. figure out exactly which line is the
Keywords
line, etc.
  
   Grep for a line that starts with
#: ../
   and includes the string
   .desktop.in.in.h:
   then find the next line that starts with
   msgid
   and ends with
   ;
   then count the number of ; in that specific line,
   compare that number with the next line that starts with
   msgstr
   and which is not
   msgstr 
   which would mean not translated yet.
   Trigger a warning if the number is not the same.
   Or something like that. Cough. Sounds error-prone.
  
   andre
   --
   Andre Klapper  |  ak...@gmx.net
   http://blogs.gnome.org/aklapper/
  
   ___
   gnome-i18n mailing list
   gnome-i18n@gnome.org
   https://mail.gnome.org/mailman/listinfo/gnome-i18n
  
  
  
   ___
   gnome-i18n mailing list
   gnome-i18n@gnome.org
   https://mail.gnome.org/mailman/listinfo/gnome-i18n
  
 
 


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: keywords in desktop files, again

[Ask Hjorth Larsen]

Hi, here's a script (uses pyg3t):

  http://www.student.dtu.dk/~ashj/opendir/desktopfilecheck.py

I'm actually at work at the moment, but someone can run it or I'll do
it tomorrow or so when I have time.

Let me know about any issues or if it needs to check for anything else.

Regards
Ask

2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
 Hi Ask,

 The Keywords string just has to end with ; to be ok, no need to have the
 same number of words

 Many thanks fin advance for your script!


 2013/3/22 Ask Hjorth Larsen asklar...@gmail.com

 Hi

 Could someone specify how these files *should* be translated?  Must
 there be the same number of elements in the list?

 I suppose the most obvious thing is that it should end with ;.

 I'll write a script and check it on all the files, then send a complete
 list.

 Regards
 Ask

 2013/3/22 Daniel Mustieles García daniel.mustie...@gmail.com:
  In bash it may be tricky to do this check, but I guess Python could
  help. I
  tried to do it in bash and I wasted my time :(
 
 
  2013/3/22 Andre Klapper ak...@gmx.net
 
  On Fri, 2013-03-22 at 15:46 +0100, Olav Vitters wrote:
   Any idea how that could be implemented? I am willing to make it
   happen,
   just don't see how. E.g. figure out exactly which line is the
   Keywords
   line, etc.
 
  Grep for a line that starts with
   #: ../
  and includes the string
  .desktop.in.in.h:
  then find the next line that starts with
  msgid
  and ends with
  ;
  then count the number of ; in that specific line,
  compare that number with the next line that starts with
  msgstr
  and which is not
  msgstr 
  which would mean not translated yet.
  Trigger a warning if the number is not the same.
  Or something like that. Cough. Sounds error-prone.
 
  andre
  --
  Andre Klapper  |  ak...@gmx.net
  http://blogs.gnome.org/aklapper/
 
  ___
  gnome-i18n mailing list
  gnome-i18n@gnome.org
  https://mail.gnome.org/mailman/listinfo/gnome-i18n
 
 
 
  ___
  gnome-i18n mailing list
  gnome-i18n@gnome.org
  https://mail.gnome.org/mailman/listinfo/gnome-i18n
 


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Commit Danish translation of gnome-online-accounts please

[Ask Hjorth Larsen]

Dear i18n people

Would you mind committing the Danish translation of
gnome-online-accounts?  Deadline is today, I hope there's time left.

http://www.student.dtu.dk/~ashj/opendir/gnome-online-accounts.gnome-3-6.da.po

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Commit Danish translation of evolution

[Ask Hjorth Larsen]

Hi

Sorry, it appears Kenneth already sent the same request.  Please ignore mine.

2012/9/24 Ask Hjorth Larsen asklar...@gmail.com:
 Hi i18n'ers

 Could one of you please commit the attached Danish translation of
 evolution by Flemming Christensen?  (Our coordinator is unavailable at
 the moment and it's quite close to deadline as you know.  Sorry for
 disturbing)

 Regards
 Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Repetitive strings in many modules

[Ask Hjorth Larsen]

Hi

2012/9/16 Chris Leonard cjlhomeaddr...@gmail.com:
 On Sat, Sep 15, 2012 at 9:04 PM, Ask Hjorth Larsen asklar...@gmail.com 
 wrote:
 Hi translators and i18n people

 I notice that the string Quit seems to have appeared in quite a few
 modules.  In total, the msgids Quit or _Quit (i.e. matching
 ^(_?)Quit$) are found 31 times, in these modules:


 Why not use a stock label for this kind of stuff?  There are also many
 instances of About and _About which I don't recall from previous
 releases.

 Regards
 Ask


 Yes, Strings like this are a good reason to use an off-line PO editor
 with a good translation memory feature or an on-line tool like Pootle
 that has a glosssary/terminology project.  It would be a thought to
 crunch a glossary.po terminology project  for GNOME using
 poternimology from theTranslate Toolkit.  At the very least, people
 could download it to their local TM to help maintain consistency in
 translations of certain common terms.

I don't really mind *translating* them - they are very small strings
in any case.  But they have to be reviewed and go through the whole
procedure, and it adds up a bit no matter whether you have a
compendium or not (a compendium helps a lot with the license texts
though).  But it was my impression that one instead uses stock labels
like the Save as... and About.  Don't we have those?

Also, not too many releases ago something similar happened where
several messages appeared in many modules.  Like Unrecognized desktop
file version (I still remember that one).  It's a bit strange, that's
why I ask.

Regards Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Errors in documentation tags

[Ask Hjorth Larsen]

Hi

2012/9/16 Piotr Drąg piotrd...@gmail.com:
 2012/9/15 Alexandre Franke alexandre.fra...@gmail.com:
 Can you try amp; as a replacement of the ampersand and see if it
 fixes the error? If it doesn't work, try with %26.

 Please note that a file has been uploaded to Vertimus for this
 translation (so fixing it in master may not be the right choice as the
 fix may be lost when commiting the new file).


 I don't have access to the script, so I can't check if it would help.

If you just need to run it on one file, use 'gtxml filename.po'.
gtxml is part of pyg3t and can be found here:

  https://launchpad.net/pyg3t

Note that gtxml only verifies that the xml isn't broken.  (One can
still write valid xml using tags which are not recognized in the GNOME
docs, and thus wrong)

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Repetitive strings in many modules

[Ask Hjorth Larsen]

Hi translators and i18n people

I notice that the string Quit seems to have appeared in quite a few
modules.  In total, the msgids Quit or _Quit (i.e. matching
^(_?)Quit$) are found 31 times, in these modules:

anjuta.master.da.po: 1
baobab.master.da.po: 1
cheese.master.da.po: 1
   devhelp.master.da.po: 1
   empathy.master.da.po: 1
   eog.master.da.po: 1
  epiphany.master.da.po: 1
 evolution.master.da.po: 1
   file-roller.master.da.po: 1
 gcalctool.master.da.po: 1
 glade.master.da.po: 1
   gnome-bluetooth.master.da.po: 2
   gnome-boxes.master.da.po: 1
gnome-contacts.master.da.po: 1
  gnome-control-center.master.da.po: 1
  gnome-dictionary.master.da.po: 1
gnome-disk-utility.master.da.po: 1
   gnome-documents.master.da.po: 1
 gnome-font-viewer.master.da.po: 1
   gnome-games.master.da.po: 1
  gnome-packagekit.master.da.po: 1
  gnome-screenshot.master.da.po: 1
   gnome-shell.master.da.po: 1
  gnome-system-log.master.da.po: 1
  gtk+.master.da.po: 1
   libgtop.master.da.po: 1
  nautilus.master.da.po: 1
   nemiver.master.da.po: 1
  totem.gnome-3-6.da.po: 2

Why not use a stock label for this kind of stuff?  There are also many
instances of About and _About which I don't recall from previous
releases.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Errors in documentation tags

[Ask Hjorth Larsen]

Hi

2012/9/13 Daniel Mustieles García daniel.mustie...@gmail.com:
 Hi all,

 I've generated several reports, one for each language, about errors in tags
 in the documentation PO files. In the attatched file, you will find several
 language-report.txt files, with the corresponding errors to your language.
 You can cat the file and the errors will be highlighted in red. If you don't
 see your language listed in the file, it means it has no errors :)

 Please fix and update your translations, since this kind of errors in PO
 files can generate several errors when compiling the module

 This report has been generated using gtxml and a very simple bash script. If
 you are interested on it, of course I can send you the bash script I've
 generated. Also, if you want to improve it, you will be free to do it.

 Best regards

 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 https://mail.gnome.org/mailman/listinfo/gnome-i18n


Thanks for doing this, Daniel.

A tip to everyone: Open the txt files with less -R.  Then it will
colour the locations of the xml errors.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Mistakes in doc translations

[Ask Hjorth Larsen]

Hi

On Thu, 19 Apr 2012, Jiro Matsuzawa wrote:


Hi all,

As Chusslove says, version control of PO is more difficult than that
of normal source files.
But there are tips on how to manage PO on VCS.
1. --no-wrap
2. --no-location

The above points are msgmerge's options. Msgmerge with --no-wrap does
not wrap texts. That gets rid of noise from rewraps.
And --no-location is also useful. That removes location information
which causes conflicts.

Please refer to the following PO diff.
http://git.gnome.org/browse/gnome-user-docs/commit/gnome-help/ja/ja.po?id=dc7c0d447e510dd25d15b73cc7462bf79f623d69

The PO file was msgmerged with --no-wrap and --no-location. Commits of
the po indicate no inessential and noisy diff which makes version
control of PO difficult.
In a word, it's important to remove information and format
automatically generated.

Thanks,


If the source file information is removed, then it is difficult to find 
the strings in the source.  That makes it difficult to translate 
complicated strings where more context is needed.  This is only something 
I personally do when I really have to, but it's important to keep the 
source file information for this reason.


Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Mistakes in doc translations

[Ask Hjorth Larsen]

Hi

On Wed, 18 Apr 2012, Shaun McCance wrote:


On Wed, 2012-04-18 at 10:40 +0200, Chusslove Illich wrote:

[: Shaun McCance :]
The answer is plainly yes, if you use version control correctly. PO files
might have some characteristics that make some things harder, but they're
not so special that they're outside the realm of git.


But PO files are the furthest outwards in the realm of Git (version control
in general). I'm looking for ways to close them in.


I'm pretty sure that distinction belongs to PNG files. :)


PO files are more line-oriented than XML files. Will you get diff noise
from rewraps? Sure.


Documentation XML files may be slightly more special than program code, but
for the single reason you mention, text wrapping. And I've heard that
powerful diff tools that can work around it (Emacs I think). Also, I
personally never word-wrap text in XML files, so in my uses XML files are
exactly same as source code.


There are amazing XML diff tools out there. And if there aren't amazing
PO diff tools out there, somebody needs to write one. Heck, I've even
seen image diff tools, which is incredible. But pulling and merging in
git, all that matters is the line diff.



pyg3t contains podiff which ignores wrapping.  However this is hardly 
likely to make it into git, and so will not really solve the problem.



I do wrap lines in XML at somewhere around 80-100 characters, and I
encourage all the doc team contributors to do the same. The reason is
that, if you have a 800-character line, and you change a letter, it's
really hard to figure out what's going on in the diff.

For the same reason, I encourage people not to rewrap all the lines
in a paragraph when adding a word or two. Yes, it leads to more ragged
right edges. But it makes the diffs so much cleaner. Line wrapping is
good. Automatic rewrapping is a pain.


So here's a summary of the things that cause problems, as I understand
it. Correct me if I'm wrong.

1) Automatic rewrapping creates lots of noise and can confuse merges.
2) Multiple people merging the POT file creates conflicts.
3) Messages get reordered, which creates complete noise in diffs.
4) Due to workflow, we don't have a baseline commit to reference.

(4) is a serious problem. git is really smart, and has a number of
merge strategies that I can only describe as magic. But they don't
work if you bypass version control.

(1) and (3) totally suck, and I think reflect problems in the tools
translators use. It's like the tools are actively trying to prevent
you from having meaningful version control.

I'd be surprised if git couldn't manage to deal with (2), given that
it ought to be the exact same changes introduced. For my part, I can
guarantee that I'll never commit those kinds of changes.

Do we really not have any tools to help translators merge two sets
of changes? That seems like it should be a solved problem.


Which criterion would one use to merge them?  Supposedly one would choose 
strings from one changeset above the other, and then include as many 
translations as possible.  Would that be the idea?



Anyway, if there are problems that break the build (less common with
recent itstool improvements), then my choices are to fix them or to
disable the translation. I'm not in the habit of building daily, so
if I have to disable a translation, it probably means it's disabled
in the release. And that would be a real shame. You guys do too much
awesome work for it to be wasted like that.

--
Shaun


In my opinion it is fine to fix critical syntax errors by hand. 
Translators should be able to deal with changes in the po/pot-file at any 
time, as the is updated at arbitrary times already.  This seems like 
simply a practical issue, as the one who finds the syntax error can 
probably even fix it faster than it would take to communicate its location 
to the translators.


Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Diffing POT files

[Ask Hjorth Larsen]

Hi

On Thu, Mar 22, 2012 at 4:20 PM, Chris Leonard cjlhomeaddr...@gmail.com wrote:
 I frequently encounter situations where I am interested in comparing
 POT files that are closely related, but not 100% identical.

 Does anyone know of a tool or scriptable series of actions using
 Translate Toolkit modules (or other common text manipulation tools)
 where it is simple to determine the differences between two POT files
 (e.g. two versions of the same project at differnt points in time,
 etc.).

 I imagine something like a podiff or a pounique operation where there
 are two inputs (file1.pot and file2.pot) and the output might ideally
 be three files that represent the textual equivalent of a Venn diagram
 of these two files.

 file1-unique.pot
        msgids (still in a nice POT format) that are unique to file1

 file2-unique.pot
        msgids (still in a nice POT format) that are unique to file2

 file1-file2 common.pot
        msgids (still in a nice POT format) that represent the completely
 identical msgid overlap between file1.pot and file2.pot.

 This process should not permit fuzzy matching, which could lead to confusion.

 Does anyone know of such a tool?  It would ideally be aware of PO file
 structure to treat string subunits of a PO file as a single chunk as
 opposed to a simple *nix diff which would be line-by-line.

 Alternatively, does any one have an algorithm employing Transalte
 Toolkit modules to achieve the same or similar result that could be
 turned into a shell script that involves minimal manual manipulation
 of the input of output files to achieve this sort of POT comparison
 result.

 TIA for any ideas or suggestions.

 cjl
 Sugar Labs Translation Team Coordinator

Not quite, but pyg3t contains a tool called gtcompare which will give
a qualitative overview of the differences between two files (useful
e.g. if there are conflicting changes and you want to see roughly how
bad things are)

For example here's some output comparing before and after a recent
translation of mine:

--
askhl@mime:~/Downloads$ gtcompare old/gnome-disk-utility.master.da.po
gnome-disk-utility.master.da.po
Each file contains 425 msgids, and they are all identical.

0 messages remain untranslated.
0 untranslated messages changed to fuzzy.
5 untranslated messages changed to translated.
0 fuzzy messages changed to untranslated.
0 messages remain fuzzy.
28 fuzzy messages changed to translated.
0 translated messages changed to untranslated.
0 translated messages changed to fuzzy.
392 messages remain translated.

There are no conflicts among translated messages.
---

Right now the script has no options.  Maybe we should implement an
option to print the actual messages in specified categories.  This
would be exceedingly easy I think.  What would be a good syntax?
Something like:

gtcompare --fuzzy2translated --untranslated2fuzzy file1 file2

(a bit long)

Or:
gtcompare --print f2t,u2f file1 file2

(rather ugly)

Any ideas?

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: bug 551859 - translating aisleriot card movement hints

[Ask Hjorth Larsen]

On Sun, Sep 25, 2011 at 1:16 AM, Vincent Povirk madewokh...@gmail.com wrote:
 If proper gettext context is not supported, an old workaround is to use

 msgstr nominative|Queen of Spades

 and then have the programme strip off the nominative| part.
 Although this is not considered a very good solution.  Also it would
 be necessary with a comment instructing translators to ignore the part
 nominative|.

 I, er, don't think we can do comments either.


Okay, I suggest following your suggestion, which was to have three
families of strings (quoting):

* the Ace of Hearts
* Move %s onto the Queen of Spades.
* Move the Ace of Hearts onto an empty foundation slot.

except in the last one, I think Move %s onto an empty foundation
slot. is better. You also suggested this in the bugzilla thread, and
although there were comments after that, they didn't specifically say
that there was anything wrong with doing it that way.  It's the
simplest possible string substitution, and unless someone specifically
says this is broken in the  language, then we have to assume it is
alright.  In fact I don't even see how this case is dissimilar from
case 2).

I hope this will make things easier for everyone.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: bug 551859 - translating aisleriot card movement hints

[Ask Hjorth Larsen]

Hi

On Sat, Sep 24, 2011 at 8:01 PM, Vincent Povirk madewokh...@gmail.com wrote:
 Ihar Hrachyshka has revived the discussion on
 https://bugzilla.gnome.org/show_bug.cgi?id=551859, which is a bug
 about how we can't properly translate sentences like Move the Ace of
 Hearts onto the Queen of Spades.

 In order to avoid having  54 times 54 strings for this, we substitute
 the individual card names into something like Move %s onto %s. I
 understand that in many languages a different string is required for
 the first and second value, so this doesn't work.

 The way I'm currently planning to fix it, we would have the following
 kinds of strings:

 * the Ace of Hearts
 * Move %s onto the Queen of Spades.
 * Move the Ace of Hearts onto an empty foundation slot.

 There would be 54 of the first and second kind. There would probably
 be more than a hundred and less than a thousand of the third kind,
 depending on how many non-card things we need to generate hints for
 moving specific cards to. Card name strings would only be substituted
 into those 54 sentences for moving onto a specific card.

 If I get no response here (which I'm sort of expecting), that is what
 I will do. I'll be doing my work on the master branch as strings are
 frozen in 3.2.

 Is creating one string for each combination of cards actually better,
 in spite of my instincts that tell me not to do that?

 Is there some other solution that gives translators more flexibility
 without creating more strings?

 I get the impression that msgctxt would make the strings shorter but
 not actually reduce their number, and since I do not know how to set
 up msgctxt properly for use in scheme code I figure it's better to
 ignore it so I can make progress.

 I am not subscribed to this list, so please CC me on replies.

I think the third category can be avoided.

Was there any reason not to follow Andre Klapper's suggestion from the
bugzilla link?

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: bug 551859 - translating aisleriot card movement hints

[Ask Hjorth Larsen]

On Sat, Sep 24, 2011 at 9:35 PM, Vincent Povirk madewokh...@gmail.com wrote:
 Was there any reason not to follow Andre Klapper's suggestion from the
 bugzilla link?

 If you're referring to comment 9, we do not currently have the ability
 to include a context with our strings. I do not understand the tools
 well enough to make this work.


If proper gettext context is not supported, an old workaround is to use

msgstr nominative|Queen of Spades

and then have the programme strip off the nominative| part.
Although this is not considered a very good solution.  Also it would
be necessary with a comment instructing translators to ignore the part
nominative|.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: gnome-dvb-daemon

[Ask Hjorth Larsen]

Hi Claude

On Sun, Apr 17, 2011 at 8:27 PM, Claude Paroz cla...@2xlibre.net wrote:
 Hi translators,

 I added gnome-dvb-daemon to l10n.gnome.org. As existing translations
 were imported from Launchpad, you may want to check the quality.

 http://l10n.gnome.org/module/gnome-dvb-daemon/

 Cheers,

 Claude

 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 http://mail.gnome.org/mailman/listinfo/gnome-i18n


Thank you.

Are translations of gnome-dvb-daemon disabled in Launchpad now?  They
seem to be according to:

  https://translations.launchpad.net/gnome-dvb-daemon

(things are easier to figure out when there is only one place to
translate a module)

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: What is reduced translation?

[Ask Hjorth Larsen]

Hi Nguyen

On Sun, Apr 10, 2011 at 3:22 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
 Hi,

 How is it different from the normal translations in damned lies?
 --
 Duy
 ___
 gnome-i18n mailing list
 gnome-i18n@gnome.org
 http://mail.gnome.org/mailman/listinfo/gnome-i18n


The reduced po-files exclude certain messages (description strings for
gconf settings) that do not appear directly in the program.  So if you
want to save time you can translate only the reduced po-files
containing the more important messages.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: please commit Danish translations

[Ask Hjorth Larsen]

On Sun, Apr 3, 2011 at 5:42 PM, Kenneth Nielsen k.nielse...@gmail.com wrote:
 2011/4/3 Ask Hjorth Larsen asklar...@gmail.com:
 Dear committers

 As our coordinator Kenneth Nielsen is busy tomorrow, could one of you
 please commit the three Danish po-files in this tarball?

 It turned out that is was quite easy to get on the internet at my
 temporary resident in Leiden, Holland, so I can commit these my self
 now, unless someone has already done it.

 \Kenneth

  http://www.student.dtu.dk/~ashj/pofiles-da.tar.gz

 They are for evolution, empathy and orca.

 Best regards
 Ask Hjorth Larsen

Thank you Kenneth

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

please commit Danish translations

[Ask Hjorth Larsen]

Dear committers

As our coordinator Kenneth Nielsen is busy tomorrow, could one of you
please commit the three Danish po-files in this tarball?

  http://www.student.dtu.dk/~ashj/pofiles-da.tar.gz

They are for evolution, empathy and orca.

Best regards
Ask Hjorth Larsen
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Variables placheholders comment

[Ask Hjorth Larsen]

Hi

On Mon, Mar 28, 2011 at 5:54 PM, dooteo doo...@zundan.com wrote:
 Hi all,

 There is a comment into gnome-packagekit which makes me doubt about my
 faith in gettext.

 Here is the comment:

        #. TRANSLATOR: %i %s %i %s are %i minutes %i seconds
        #. * Swap order with %2$s %2$i %1$s %1$i if needed
        #. TRANSLATOR: %i %s %i %s are %i hours %i minutes
        #. * Swap order with %2$s %2$i %1$s %1$i if needed

 but, as far as I know, swap order (if translation needs) should be:

        %4$s %3$i %2$s %1$i (which outputs such as 'seconds number minutes
 number' message)

 So, placeholders should be unique. Am I wrong?

 Best regards,

 Dooteo

You can validate the substitution codes with msgfmt -cv filename.po.
 It should complain if the substitution codes are wrong.

If the translator comment is wrong, I guess one should file a bug
report with gnome-packagekit.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problem msgid_plurar un msgstr[0]

[Ask Hjorth Larsen]

On Sun, Feb 27, 2011 at 2:58 PM, pec...@gmail.com pec...@gmail.com wrote:
 Hi people!

 This is problably said before, but as I couldn't google for proper
 answer, I will ask (propably again) here:

 I have banshee except from my language's po which looks something like this:
 msgid Transferring {0} file at {1} KB/s
 msgid_plural Transferring {0} of {2} files at {1} KB/s
 msgstr[0] Pārsūta {0} failu ar ātrumu {1} KB/s
 msgstr[1] Pārsūta {0} no {2} failiem ar ātrumu {1} KB/s
 msgstr[2] Pārsūta {0} no {2} failiem ar ātrumu {1} KB/s

 Now, msgfmt -c banshee.lv.po issues fatal error for this:
 banshee.master.lv.po:6131: number of format specifications in
 'msgid_plural' and 'msgstr[0]' does not match

 Question is - how I can properly translate singular (aka msgid)?
 msgstr[0] is compared to msgid_plurar, which is wrong.

 Thanks in advance,
 Peter.

Very strange.  Are you sure the plural definition (in the program
header) is written correctly?  It's not uncommon to have a different
number of format specifications in the singular/plural English
strings, so I think it should work in general.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translating schema files (was: Re: Survey results (yay!))

[Ask Hjorth Larsen]

On Mon, Nov 1, 2010 at 4:38 PM, Gil Forcada gforc...@gnome.org wrote:
 El dl 01 de 11 de 2010 a les 00:21 +0200, en/na Simos Xenitellis va
 escriure:

 On Sun, Oct 31, 2010 at 11:25 PM, jbow...@amathaine.com
 jbow...@amathaine.com wrote:
         Speaking as a small team coordinator struggling to recruit
         people and
         get them active, I have to agree this is a big issue - I don't
         know
         how we'll ever make it to 20%, much less 80%. The problem is
         that most
         people take one look at a file filled with error messages and
         schema
         strings and I never hear from them again. I *only* get
         contributions
         when I can tell them *exactly* which strings in the file
         correspond to
         buttons/menus/labels.  Guess what?  I can't do that on my own
         for most
         modules, which is why over the last few years our stats have
         actually
         dropped from nearly 5% to 1%. In fact, I don't think I've
         landed a
         single contribution since the switch to Git (though there have
         a been
         a few drive-by translations via Ubuntu).

         I don't know how many of the other languages languishing at
         the bottom
         of the list are facing the same issue, but I'll bet it's a
         fair
         number. I can swear to you that if I could get a fair number
         of the UI
         elements translated (say, 20% by D-L stats), we would see a
         big surge
         in contributions and maybe even sponsorship from the Language
         Commission.

         I mean, gtk+ is my favorite example here; the first string is
         Error
         parsing option --gdk-debug, while the stock labels (which is
         frankly
         all I care about given our general lack of coverage) are down
         somewhere around 450 strings in. 99% of my users are never
         going to
         see any of the command-line stuff in the gtk+ module, but 100%
         of them
         are going to encounter the stock labels. Why should I *have*
         to
         explain all this stuff to every potential recruit? It's hard
         enough
         just finding people who are willing to contribute in the first
         place;
         then the first thing they see is the sea of technical messages
         and
         their motivation just evaporates.



 Thanks for describing this eloquently.


 Of course, fully translated GNOME means all files translated, but it's
 nice to have this intermediate goal where you translate the most
 visible strings.

 My suggestion would be to have a parallel page (let's call it
 Compact), similar to your
 http://l10n.gnome.org/languages/el/gnome-3-0/ui/
 which would show the reduced PO files, after the filtering to remove
 schema/error/etc strings.
 This filtering would take place only in damned-lies.

 What damned-lies would do for each PO file that appears in the Compact
 page of statistics,
 1. For each message in the PO file
 2.    If the message is already translated or fuzzy, add it anyway to
 the Compact PO file
 3.    If the message is not important (schema, CLI error message,
 etc), ignore it
 4.    Add the remaining messages to the Compact PO file

 Due to this, it would be fine to commit these reduced PO files, and
 you would not lose data.

 What would the translators do,
 1. If you are a new team (few translations), do translations on the
 Compact page at damned-lies, until you complete them all fully. Once
 you achieved the first translation goal, go to the regular page for
 your language to continue the full translations, schemas, error
 messages and so on.
 2. If you are an experienced team with good level of translations,
 ignore the Compact page and translate as you always have been doing.

 I would call this special page,
 http://l10n.gnome.org/languages/el/gnome-3-0/compactui/
 (note the 'compactui').

 There is the issue of having both
 http://l10n.gnome.org/languages/el/gnome-3-0/ui/
 and
 http://l10n.gnome.org/languages/el/gnome-3-0/compactui/
 at the same time.
 It would be ideal if the team coordinator for each language could set
 in the Preferences for their language to show either one or the other
 page for the UI translations. That is, you go to
 http://l10n.gnome.org/teams/LL for your language and it shows by
 default either the full UI translations URL or the Compact URL.


 Nice approach!

 Splitting translations as in schemas and others can be quite easy. The
 more problematic ones are the splitting the errors, would make sense to
 add a keyword on msgctxt (i.e. ERROR: the actual context text)? That
 way we could manually fix the files ourselves.

 Cheers,

 Simos

There's no automatic way to split errors from the GUI strings, so
it'll be a huge amount of work for programmers (and require sustained
maintenance work), while the benefit to translators is not significant
IMHO.  But I'd really like to see all the useless schema 

Re: Translating schema files (was: Re: Survey results (yay!))

[Ask Hjorth Larsen]

2010/11/1 Jorge González González alor...@gmail.com:

 There's no automatic way to split errors from the GUI strings, so
 it'll be a huge amount of work for programmers (and require sustained
 maintenance work), while the benefit to translators is not significant
 IMHO.  But I'd really like to see all the useless schema strings
 separated out.
 IMHO error and schema strings should not be translated. Whenever I try
 to find help in Spanish when a software crashes, I usually get few or
 null feedback from the error in Spanish (in my case), but tones of pages
 and websites when I paste the same error in English into Google.

What are error messages then?  'Illegal move' in chess should
definitely be translated. 'Could not connect to server' should be
translated also.  A message about not being able to access some file
should also be translated.  I don't think there are a lot of errors
where it makes sense to keep them in English.

 And the normal user will never search for those errors, only advanced
 users, so I guess we're not helping them much translating error and
 schema messages.

 Besides, I bet there are hundreds of strings in GNOME that the final
 user will NEVER, ever see.

Thousands, most of which we'll get rid of by separating out the schemas.

Regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n