Re: [Freeipa-devel] Reviving FreeIPA translations
2016-05-13 13:32 GMT+02:00 Martin Kosek <mko...@redhat.com>: > Hello, > > As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat > employee, which of course does not mean he cannot contribute to the FreeIPA > project, but that he won't have as much time for contributions as > previously. > > One of Tomas' responsibilities was taking care of FreeIPA translations > (Translation Maintainer role). As far as I know, there 2 main tasks > associated > with the Translation Maintainer role: > > 1) Periodically uploading new upstream strings to the FreeIPA translation > platform of choice, which is the Fedora Zanata instance: > https://fedora.zanata.org/project/view/freeipa > The upload should happen periodically, on the right occasions, so that the > translators (especially the French and Ukrainian translations which have > 100% > translated) have sufficient time to translate strings for the next version > and > do not have to translate it all in couple days before release. (This was > one of > the feedback I heard recently). > > 2) Downloading translated strings, Tomas added a short HowTo to our > Release page: > http://www.freeipa.org/page/Release#Translations > > We will need a new volunteer who would help doing 1) and 2) for the planned > releases and making sure this process runs. The first task would be > uploading > current strings in master as the next release is FreeIPA 4.4 planned for > June, > so it may be nice to already upload new strings we have in FreeIPA already > to > Zanata, so that they can be translated in sufficient time. > > Volunteer(s)? > > As part of the learning process, I think it would be useful to do more > documentation of the steps taken in every translation life-cycle, current > HowTo > in Release page is rather vague. I for example did not find information > how to > work with translation versions that I saw defined in Zanata (branching may > work > similarly as in current FreeIPA git). Thanks to the two volunteers! Looking forward to see this happen! To reiterate on Martin K. message on uploads, I'd really like to see regular strings uploads to the master branch in Zanata, say once a week or every two weeks, so that translators can work on smaller strings batches. "Release early, release oftem" :) And strings that would be translated twice in a short time span wouldn't be entirely lost because they may stay in the Zanata translation memory and could help translators finalizing dot releases if the specific branches in Zanata. And if we can see the upload to master soon, translators can start working now before the branch for the 4.4 June release. Regards, J. -- Jérôme Fenal -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] French translation for FreeIPA
2016-02-29 18:45 GMT+01:00 Jérôme Fenal <jfe...@gmail.com>: > Hi all, > > Just a quick note to let you that I completed the translation of what > was available to translate on Zanata. > > Can you please check it passes the QA, that the strings available on > Zanata are the latest ones, and that it can flow back into RHEL7? > Hello there, No news good news, or everybody is swamped in BZs? :-) Cheers, J. -- Jérôme Fenal -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] French translation for FreeIPA
Hi all, Just a quick note to let you that I completed the translation of what was available to translate on Zanata. Can you please check it passes the QA, that the strings available on Zanata are the latest ones, and that it can flow back into RHEL7? Regards, J. -- Jérôme Fenal -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Meaning of two strings in plugins/service.py
2015-07-08 9:45 GMT+02:00 Petr Vobornik pvobo...@redhat.com:
On 07/08/2015 09:31 AM, David Kupka wrote:
On 05/07/15 11:25, Jérôme Fenal wrote:
Hi,
I stumbled upon those two following strings while translating into
French, and just cannot figure out the meaning.
Str('ipaallowedtoperform_read_keys',
label=_('Failed allowed to retrieve keytab'),
),
Str('ipaallowedtoperform_write_keys',
label=_('Failed allowed to create keytab'),
),
Would it be that failure is allowed while retrieving or creating keytab?
Or...?
Thanks for helping,
Jérôme
Hi Jérôme,
I guess it should be Failed to allow retrieval/creation of keytab.
But Petr (added) is author of this code and should know better.
It's used in a following way (user abc does not exist):
ipa host-allow-create-keytab vm-121.example.com --users=abc
Host name: vm-121.example.com.com
Principal name: host/vm-121.example@example.com
Managed by: vm-121.example.com.com
Failed allowed to create keytab:
member user: abc: no such entry
member group:
member host:
member host group:
-
Number of members added 0
-
I.e., host groups, hosts, user groups, users who were not added as the ones
who are allowed to to retrieve/create keytab.
So I guess it'd be more Failed to allow retrieval/creation of keytab.
Should I propose a patch to change the sentence?
Regards,
J.
--
Jérôme Fenal
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [MAN] [PATCH] 0004 Fix phrasing in man page for stageuser.py
Hi all, A quick patch to the man page part of stageuser to avoid ambiguity in the phrasing, spotted while translating the page. Regards, J. -- Jérôme Fenal From f43c8358afceb4c8c35cbb800553dd3247905095 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Fenal?= jfe...@free.fr Date: Sat, 4 Jul 2015 13:56:24 +0200 Subject: [PATCH] Fix the man page part for shorter sentences, to avoid dual understanding, and punctuation, all spotted while translating to French. --- ipalib/plugins/stageuser.py | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/ipalib/plugins/stageuser.py b/ipalib/plugins/stageuser.py index 35e636ded4474b00ad635c60340aaf66e6b41752..0b42eae437bc1e85a5d3880dd071fd83c6bde3fe 100644 --- a/ipalib/plugins/stageuser.py +++ b/ipalib/plugins/stageuser.py @@ -50,24 +50,24 @@ Manage stage user entries. Stage user entries are directly under the container: cn=stage users, cn=accounts, cn=provisioning, SUFFIX. -User can not authenticate with those entries (even if the entries -contain credentials) and are candidate to become Active entries. +Users can not authenticate with those entries (even if the entries +contain credentials). Those entries are only candidate to become Active entries. Active user entries are Posix users directly under the container: cn=accounts, SUFFIX. -User can authenticate with Active entries, at the condition they have -credentials +Users can authenticate with Active entries, at the condition they have +credentials. -Delete user enties are Posix users directly under the container: cn=deleted users, +Deleted user entries are Posix users directly under the container: cn=deleted users, cn=accounts, cn=provisioning, SUFFIX. -User can not authenticate with those entries (even if the entries contain credentials) +Users can not authenticate with those entries, even if the entries contain credentials. -The stage user container contains entries -- created by 'stageuser-add' commands that are Posix users -- created by external provisioning system +The stage user container contains entries: +- created by 'stageuser-add' commands that are Posix users, +- created by external provisioning system. -A valid stage user entry MUST: -- entry RDN is 'uid' -- ipaUniqueID is 'autogenerate' +A valid stage user entry MUST have: +- entry RDN is 'uid', +- ipaUniqueID is 'autogenerate'. IPA supports a wide range of username formats, but you need to be aware of any restrictions that may apply to your particular environment. For example, @@ -81,7 +81,7 @@ EXAMPLES: Add a new stageuser: ipa stageuser-add --first=Tim --last=User --password tuser1 - Add a stageuser from the Delete container + Add a stageuser from the deleted users container: ipa stageuser-add --first=Tim --last=User --from-delete tuser1 ) -- 1.7.1 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Move FreeIPA translations to Zanata?
2015-01-09 15:13 GMT+01:00 Petr Vobornik pvobo...@redhat.com: On 01/09/2015 03:00 PM, John Dennis wrote: On 01/09/2015 07:42 AM, Martin Kosek wrote: I am forwarding my conversation with the Noriko from Fedora localization team to the devel list, see below. What do you guys think? Any concerns with moving FreeIPA translations from Transifex to Zanata? SSSD project is moving there as well. I have no personal experience with Zanata so my comment is worth what you paid for it :-) +1 +1 Just following the online discussions it does seem like Zanata is the future, so probably better to be using the tool everyone else is using instead of a lone hold out. Anecdotal reports suggest migrations are relatively smooth. YMMV. +1 +1 -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA translations
2014-11-12 15:22 GMT+01:00 John Dennis jden...@redhat.com: On 11/12/2014 07:44 AM, Martin Kosek wrote: Hi folks, With Petr changing focus out of FreeIPA, somebody will need to replace his work as the person behind FreeIPA Transifex translation. I think this is now the right time and place to ask - Is Transifex still the translation tool we want to continue supporting? I know there were objections in the past it is not completely open source. But AFAIK, it is one of the most used ones, even OpenStack uses it. I have not been following it closely but there was talk of both Fedora and Openstack moving from Transifex to Zanata http://zanata.org/ As a matter of fact there was recent emails concerning the new Fedora Zanta instance Move to Zanata Stage 1 - fedora.zanata instance available now! https://lists.fedoraproject.org/pipermail/trans/2014-November/011717.html Like I said, I haven't followed this closely but it seems like Zanata is the future. +1 The Fedora Zanata instance is the place to go. Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption
2013/11/15 Dmitri Pal d...@redhat.com: On 11/15/2013 04:44 PM, James wrote: On Fri, Nov 15, 2013 at 8:26 AM, Petr Vobornik pvobo...@redhat.com wrote: Example is at: http://pvoborni.fedorapeople.org/rcue/ And here I thought FreeIPA couldn't get any prettier... Nice work. +1 James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Very cool! +1 very nice. Side effect: the impact on all UI task descriptions in the documentation when a sub-menu is involved ;) -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Daily build of the documentation?
Hi all, Do we have a place where we publish a daily build of the documentation? I'd like to send such a link for documentation review by Red Hatters. Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Daily build of the documentation?
2013/10/25 Martin Basti mba...@redhat.com: On Fri, 2013-10-25 at 16:48 +0200, Jérôme Fenal wrote: Hi all, Do we have a place where we publish a daily build of the documentation? I'd like to send such a link for documentation review by Red Hatters. Regards, J. Hi, We don't have place for it yet. IMHO new doc should be published after major corrections. There is a lot of outdated sections which are unusable for freeIPA 3.3.x . I agree, but it could have the red background Draft stamp on it to indicate its status. My goal would be to have it reviewed by Red Hat SAs. I guess I could also do something internally. Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands descriptions into XML tables.
2013/10/18 Petr Viktorin pvikt...@redhat.com: On 10/15/2013 06:19 PM, Jérôme Fenal wrote: kk2013/10/15 Martin Kosek mko...@redhat.com: Thanks. It would be ideal, if this table is (in future) generated somehow semi-automatically as practically all this info can be gathered from FreeIPA code. But for now, this is great. I see some issues with the patch though: 1) Whitespaces before tabs OK, I fixed my attached script my removing leading spaces in the second part of s///. I fixed some of them with sed -i s/\+\t$/+/g /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables.patch Bug there is the second issue: 2) Testbuild fails: $ git am /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables-1.patch Applying: Split commands in proper tables /home/mkosek/freeipa-docs/.git/rebase-apply/patch:211: space before tab in indent. row /home/mkosek/freeipa-docs/.git/rebase-apply/patch:212: space before tab in indent. entry /home/mkosek/freeipa-docs/.git/rebase-apply/patch:213: space before tab in indent. automountkey-add /home/mkosek/freeipa-docs/.git/rebase-apply/patch:214: space before tab in indent. /entry /home/mkosek/freeipa-docs/.git/rebase-apply/patch:215: space before tab in indent. entry warning: squelched 1849 whitespace errors warning: 1854 lines add whitespace errors. Will look into that. Side question, how did you get the initial text command list? It looks like `ipa help commands` output. OK, I'll try give it a try to automate the creation of included files here this week-end. Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement
2013/10/14 Martin Kosek mko...@redhat.com: Thanks Jérôme, the patch is perfect now. Unfortunately I see that I cannot push it as Martin Basti's commit 0d48ee15 already fixes this spot. But please don't be afraid, there will be many other opportunities to use the newly gained FreeIPA-doc-contribution skill :) Great, thank you. And don't worry, I've got a few fixes I have to send on other files as well. Just need to find some time to prepare those using my new superpowers ;) Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [DOC] [PATCH] 0003 Remove bogus paragraph
In reformatting the last patch (which included revert my own repo), the removal of the paragraph was lost. Now removing it. Really ;) -- Jérôme Fenal freeipa-jfenal-0003-Remove-bogus-paragraph.patch Description: Binary data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement
2013/10/11 Martin Kosek mko...@redhat.com: On 10/10/2013 06:37 PM, Jérôme Fenal wrote: Attached. Replaced the dodgy sentence with Martin's one. Regards, J. Thanks Jérôme for the patch, I have few comments though: 1) One more note for patch format, please use the following command to extract your patch from git: $ git format-patch -M -C --patience --full-index -1 Source: http://www.freeipa.org/page/Contribute/Patch_Format It will maker then easier for us to merge the patch to main git tree. Done. 2) I think we should not mix indentation with spaces and tabs Switched back to noet in vim, and fixed. 3) Shouldn't we also remove the now redundant previous paragraph? A change like that: - para - A specific user or host can be removed from an SELinux map by using either the commandselinuxusermap-remove-host/command or commandselinuxusermap-remove-user/command comma... - /para Done as well, working while tired on doc cannot be spotted by a compiler... :) Let me know. -- Jérôme Fenal freeipa-jfenal-0002-Fix-broken-sentence-for-selinuxusermap-remove.patch Description: Binary data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement
Attached. Replaced the dodgy sentence with Martin's one. Regards, J. -- Jérôme Fenal freeipa-jfenal-0002-Remove-SELinux-user.patch Description: Binary data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [DOC] what was the meaning?
Hi all, Found in SelinuxMap.xml: As with adding a user to a ion value identifies the host-based access control rule to use for mapping. The access control rule must specify both users and hosts appropriately so that the SELinux map can construct the SELinux user, IPA; user, and host triple. What was ion supposed to be? Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [DOC] Use entities when citing product name
Trivial patch attached. -- Jérôme Fenal Installing-use-productname-entities.diff Description: Binary data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Changed trac wiki page for freeipa-guide
Hi there, just a quick head-up to tell I've just changed the wiki page at https://fedorahosted.org/freeipa-guide/wiki/WikiStart to reflect the new documentation process (and refer to the right git repo and freeipa.org page). Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0267 Update translations
2013/8/2 Petr Viktorin pvikt...@redhat.com Hello, I've prepared a patch with fresh translations pulled from Transifex. As usual the patch is pretty large; please download it from: https://github.com/encukou/**freeipa/compare/translations.**patchhttps://github.com/encukou/freeipa/compare/translations.patch Thank you to all translators! This time the patch also updates the Transifex URL in our config file; the old .net URL is still redirecting to the new .com, but its certificate has expired. In other news, I've set up a repo to archive the Transifex translations, and a cron job to update it periodically. The repo can be found at: https://github.com/encukou/**freeipa-translationshttps://github.com/encukou/freeipa-translations With this in place, there should be less fear of pushing source strings to Transifex. If you want to keep your own archive; my cron job goes like this: make git add po git commit -mUpdate translations (automatic commit) git push origin master In yet other news, the ticket to split long __doc__ strings is scheduled for the IPA 3.4. This time it's getting in :) https://fedorahosted.org/freeipa/ticket/3587 That's great news, Petr ! With that in place, French will soon jump to 100% ;) I'll watch the transifex resource being updated. Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0267 Update translations
2013/8/2 Petr Viktorin pvikt...@redhat.com On 08/02/2013 04:25 PM, Petr Viktorin wrote: Hello, I've prepared a patch with fresh translations pulled from Transifex. As usual the patch is pretty large; please download it from: https://github.com/encukou/**freeipa/compare/translations.**patchhttps://github.com/encukou/freeipa/compare/translations.patch Thank you to all translators! This time the patch also updates the Transifex URL in our config file; the old .net URL is still redirecting to the new .com, but its certificate has expired. In other news, I've set up a repo to archive the Transifex translations, and a cron job to update it periodically. The repo can be found at: https://github.com/encukou/**freeipa-translationshttps://github.com/encukou/freeipa-translations With this in place, there should be less fear of pushing source strings to Transifex. If you want to keep your own archive; my cron job goes like this: make git add po git commit -mUpdate translations (automatic commit) git push origin master In yet other news, the ticket to split long __doc__ strings is scheduled for the IPA 3.4. This time it's getting in :) https://fedorahosted.org/**freeipa/ticket/3587https://fedorahosted.org/freeipa/ticket/3587 The IPA team doesn't have anyone who can check translations, so self-ACK, pushed to master: 5d141bd39cb99f2c2e16b61bcc4e06b734bbab04 Great! Were the __doc__ strings splitted as well? Or are they splitted on double \n at string extraction time? Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex
No, the problem is real here : %s vs. %r... :) Will fix it. 2013/4/15 Petr Viktorin pvikt...@redhat.com Hello, Since the beta will be released soon, we should pull in all the hard work our translators have contributed. Ukrainian and French are almost complete (almost only due to our extremely lax string freeze). New languages: Catalan and Basque* Thanks to all translators! Validation finds one problem in French; it's an interesting false positive: locations: ipalib/parameters.py:1490 The following substitutions are absent in msgid: %(char)s The following substitutions are absent in msgstr: %(char)r msgid The character %(char)r is not allowed. msgstr Le caractère « %(char)s » n'est pas autorisé. The problem here is that the faux-English quotes (which %r gives) are not appropriate for French. I'm not sure yet how to best solve this. I haven't attached the patch due to its large size. Please download it from: https://github.com/encukou/**freeipa/commit/** 1b1e4129f20b44bcb650d5ffe02370**ba3fbedef2.patchhttps://github.com/encukou/freeipa/commit/1b1e4129f20b44bcb650d5ffe02370ba3fbedef2.patch -- Petr³ * plus Czech, which doesn't really count -- I used it for testing __**_ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-develhttps://www.redhat.com/mailman/listinfo/freeipa-devel -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex
Fixed ;) 2013/4/15 Jérôme Fenal jfe...@gmail.com No, the problem is real here : %s vs. %r... :) Will fix it. 2013/4/15 Petr Viktorin pvikt...@redhat.com Hello, Since the beta will be released soon, we should pull in all the hard work our translators have contributed. Ukrainian and French are almost complete (almost only due to our extremely lax string freeze). New languages: Catalan and Basque* Thanks to all translators! Validation finds one problem in French; it's an interesting false positive: locations: ipalib/parameters.py:1490 The following substitutions are absent in msgid: %(char)s The following substitutions are absent in msgstr: %(char)r msgid The character %(char)r is not allowed. msgstr Le caractère « %(char)s » n'est pas autorisé. The problem here is that the faux-English quotes (which %r gives) are not appropriate for French. I'm not sure yet how to best solve this. I haven't attached the patch due to its large size. Please download it from: https://github.com/encukou/**freeipa/commit/** 1b1e4129f20b44bcb650d5ffe02370**ba3fbedef2.patchhttps://github.com/encukou/freeipa/commit/1b1e4129f20b44bcb650d5ffe02370ba3fbedef2.patch -- Petr³ * plus Czech, which doesn't really count -- I used it for testing __**_ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-develhttps://www.redhat.com/mailman/listinfo/freeipa-devel -- Jérôme Fenal -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Confused by some messages
Ah OK, in the context of a search, that indeed makes more sense ;) Thanks! J. 2013/4/8 Petr Viktorin pvikt...@redhat.com On 04/06/2013 11:05 PM, Jérôme Fenal wrote: Same for: Issued on from Issued on to Revoked on from Revoked on to Valid not after from Valid not after to Valid not before from Valid not before to All inipalib/plugins/internal.py around line 330 These are UI labels for the options below. 2013/4/6 Jérôme Fenal jfe...@gmail.com mailto:jfe...@gmail.com Hi all, I'm currently updating the translations in French for messages in FreeIPA, but I am confused by some of them: Valid not before from this date (-mm-dd) Valid not before to this date (-mm-dd) Issued on from this date (-mm-dd) Issued on to this date (-mm-dd) Revoked on from this date (-mm-dd) Revoked on to this date (-mm-dd) May I request a native English speaker to review those in their context (certificates) and possibly clarify those? These are help strings for cert-find options. Valid not before, Issued on, etc. are terms for the validity dates of a certificate. So Valid not after from this date means that the certificate's ending date (not after) is on or after the given day. Here is the full help for context: $ ipa cert-find --help Usage: ipa [global-options] cert-find [options] Search for existing certificates. Options: -h, --helpshow this help message and exit --subject=STR Subject --revocation-reason=INT Reason for revoking the certificate (0-10) --min-serial-number=INT minimum serial number --max-serial-number=INT maximum serial number --exactly match the common name exactly --validnotafter-from=STR Valid not after from this date (-mm-dd) --validnotafter-to=STR Valid not after to this date (-mm-dd) --validnotbefore-from=STR Valid not before from this date (-mm-dd) --validnotbefore-to=STR Valid not before to this date (-mm-dd) --issuedon-from=STR Issued on from this date (-mm-dd) --issuedon-to=STR Issued on to this date (-mm-dd) --revokedon-from=STR Revoked on from this date (-mm-dd) --revokedon-to=STRRevoked on to this date (-mm-dd) --sizelimit=INT Maximum number of certs returned --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. -- Petr³ -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Confused by some messages
Hi all, I'm currently updating the translations in French for messages in FreeIPA, but I am confused by some of them: Valid not before from this date (-mm-dd) Valid not before to this date (-mm-dd) Issued on from this date (-mm-dd) Issued on to this date (-mm-dd) Revoked on from this date (-mm-dd) Revoked on to this date (-mm-dd) May I request a native English speaker to review those in their context (certificates) and possibly clarify those? Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Confused by some messages
Same for: Issued on from Issued on to Revoked on from Revoked on to Valid not after from Valid not after to Valid not before from Valid not before to All in ipalib/plugins/internal.py around line 330 Regards, J. 2013/4/6 Jérôme Fenal jfe...@gmail.com Hi all, I'm currently updating the translations in French for messages in FreeIPA, but I am confused by some of them: Valid not before from this date (-mm-dd) Valid not before to this date (-mm-dd) Issued on from this date (-mm-dd) Issued on to this date (-mm-dd) Revoked on from this date (-mm-dd) Revoked on to this date (-mm-dd) May I request a native English speaker to review those in their context (certificates) and possibly clarify those? Regards, J. -- Jérôme Fenal -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] i18n infrastructure improvements
not a problem for translators (except those using a mail based review process, where having 72 cols may help, or not). Anyway I'm just thinking of sorting the PO alphabetically - an extra option to msgattrib should do it. - Automate document the process so any dev can do it Excellent goal, we're not too far from it now, but of all the things on the list this is the most important. Indeed. Please setup automation on pushing strings to Transifex, ideally in a master branch. Then each time a new significant release is prepared: - advertise the strings freeze, - possibly create a specific branch in Transifex, using available translations from the master branch, - advertise the new branch for translators to work on it. My 2 cents, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] i18n infrastructure improvements
2013/1/11 John Dennis jden...@redhat.com On 01/11/2013 02:44 PM, Jérôme Fenal wrote: 2013/1/11 John Dennis jden...@redhat.com mailto:jden...@redhat.com Thank you Jérôme for your insights as a translator. We have a lop-sided perspective mostly from the developer point of view. We need to better understand the translator's perspective. You're welcome. I'm not an expert at Transifex though. I've yet to schedule a lunch with Kevin Raymond (he works a few kms away from the French Red Hat office) who is coordinating the whole Fedora translation effort, but customers first, yada yada... :) I'm not sure how splitting text into smaller units gives more context but I can see the argument for each msgid being a logical paragraph. We don't have too many multi-paragraph strings now so it shouldn't be too involved. One issue also discussed on this list is the problem of 100+ lines strings in man pages generated from ___doc___ tags in scripts. Those are a _real_ pain for translators to maintain when only one line is changed. I still think TX should attempt to match the msgid from a previous pot with an updated pot and show the *word* differences between the strings along with an edit window for the original translation. That would be so useful to translators I can't believe TX does not have that feature. All you would have to do is make a few trivial edits in the translation and save it. I agree with you. But transifex developers seem to be overloaded at the moment. I can check with Kevin (and internally) if Zanata would provide a better home to host the translation effort. But heck, I'm not a translator and I haven't used the translator's part of the TX tool much other than to explore how it works (and that was a while ago). I can understand that... :) Hopefully, the IPA dev team is mutllingual ;) I'd see a few remarks here: - this massive .po file would grow wildly, especially when a typo is corrected in huge strings (__doc___), when additional sentences are added to those, etc. - breaking down bigger strings in smaller ones will certainly help here in avoiding duplicated content, - in Transifex, it is easy to upload a .po onto another branch, and only untranslated matching strings would be updated. I used it on ananconda where there are multiple branches between Fedora RHEL5/6 master, that worked easily without breaking anything. When you say easy to upload a .po onto another branch I assume you don't mean branch (TX has no such concept) but rather another TX resource. Anyway this is good to know, perhaps the way TX handles versions is not half as bad as it would appear. You're right. See how anaconda is organized, for instance: https://fedora.transifex.com/projects/p/fedora/language/en/?project=2059 Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] i18n infrastructure improvements
2013/1/11 John Dennis jden...@redhat.com On 01/11/2013 04:00 PM, Jérôme Fenal wrote: When you say easy to upload a .po onto another branch I assume you don't mean branch (TX has no such concept) but rather another TX resource. Anyway this is good to know, perhaps the way TX handles versions is not half as bad as it would appear. You're right. See how anaconda is organized, for instance: https://fedora.transifex.com/**projects/p/fedora/language/en/** ?project=2059https://fedora.transifex.com/projects/p/fedora/language/en/?project=2059 We follow the same model as anaconda, a new TX resource per version. Yup. Minus the frequent updates on master/head resource ipa (and no IPA 3.x resource, but that is not a problem for IPA, given its fast pace and no long maintenance on older branches). -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
2012/11/26 Loris Santamaria lo...@lgs.com.ve El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribió: On 11/01/2012 10:00 AM, Loris Santamaria wrote: Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. As for linking SIP users to real people, it would be great to link the asteriskSIPuser object to an IPA user, but probably not all organizations interested in this kind of functionality for Asterisk would manage all of their users with IPA. What if the real user belongs to a trusted directory, for example? So it seems that for simplicity's sake we will have to store the name of the person using the phone in the asteriskSIPuser description attribute. Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html it doesn't seems clear to me how to have an extra category of configuration pages added to the Web UI without modifying the main IPA page. What is the proper way to add extra pages to the web UI ? Thanks in advance for your input! Hello Loris, Sorry for the delay. I finally got a moment to read about Asterisk and looked into your plans. Based on what you are proposing there is no real tight integration between IPA identities and services provided by IPA and Asterisk. What I see is IPA's DS would just be used as a data store for Asterisk configuration data and it would be managed via CLI leveraging the plugin framework we put together. If such approach is interesting for a customer I do not see a reason why it should not be done. I also do not see a value of having such plugin as a part of the integrated IPA supported offering. It is too independent and far from the core for us. But it is definitely a starting point. It might change over time. Hi Dmitri, sorry for my late response, I was on vacation and just now resuming work on this plugin. I agree with you, this plugin while it could be useful to a number of sysadmins it is not really part of an identity management solution. Hi all, Wild question related to this one: would it be possible to add a plugin deployment/activation mechanism to allow admins to easily add such plugins maintained outside the IPA main tree? And a centralized repository (or at least directory) for those community plugins? Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0079 Update the pot file (translation source)
2012/9/17 Petr Viktorin pvikt...@redhat.com On 09/14/2012 09:36 PM, Jérôme Fenal wrote: 2012/9/14 Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com I pushed the pot manually. Since we have infrequent explicit string freezes I don't think it's necessary to configure automatic pot updates again. Thanks Petr! Actually, having the strings updated on Transifex on a regular basis makes it (IMHO) more manageable for translators to update the translations even before a string freeze. Translating a dozen strings per week is lighter than a mere 339 strings. A possible problem with this approach is that the translators would see and translate messages that don't make it into the final version. Do you think a more even workload would be worth the occasional extra work? Having some extra work from time to time is OK. Having a huge batch of strings to translate on a deadline is uneasy. Especially with day job ramping up... ;-) I would like to change our i18n workflow/infrastructure. I was planning to (re-)start discussing this after the 3.0 release rush is done. It should be possible to do what you suggest. Cool, thanks. I also don't know if pulls from Transifex or push from your side has an effect of keeping memory (in suggestions) of past or close enough strings from the past for small modifications. Sadly, I don't know much about Transifex itself. Perhaps ask the team there, and request the feature if it's missing. This item is not that important, more a wish. Another comment/request, I don't know given my zero-level Python-fu: would it be possible to break down the huge __doc__ strings in plugins into smaller parts, as a small modification would impact a smaller strings, easing maintenance instead of trying to track the one character modification in a 2000 chars text. Does Python support concatenations of __doc___ strings? That is be possible on the Python side. I'm not sure how Transifex (and other translation tools) would cope with text split between several messages -- sorting and filtering the messages could take things out of context. I'm aware of this issue, translators for others languages may raise their hands. I could also probe trans@fp.o on that matter, to reach all of them. That will nevertheless make changes more atomic, and overall easier to manage on the longer term. In the past, changes were just a matter of adding one paragraph, or adding one more usage example. Or fixing a typo. Which is way harder to spot when you have a 1000 chars strings tagged as changed. Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0079 Update the pot file (translation source)
2012/9/14 Petr Viktorin pvikt...@redhat.com On 09/13/2012 09:21 PM, Rob Crittenden wrote: Petr Viktorin wrote: Transifex is watching our repository, so pushing this patch will update the translations on the site. Okay, I lied. Some time ago (before I joined), Transifex changed its watching mechanism from VCS pulls to URL polling. I guess IPA got unwatched then. I pushed the pot manually. Since we have infrequent explicit string freezes I don't think it's necessary to configure automatic pot updates again. Thanks Petr! Actually, having the strings updated on Transifex on a regular basis makes it (IMHO) more manageable for translators to update the translations even before a string freeze. Translating a dozen strings per week is lighter than a mere 339 strings. I also don't know if pulls from Transifex or push from your side has an effect of keeping memory (in suggestions) of past or close enough strings from the past for small modifications. Another comment/request, I don't know given my zero-level Python-fu: would it be possible to break down the huge __doc__ strings in plugins into smaller parts, as a small modification would impact a smaller strings, easing maintenance instead of trying to track the one character modification in a 2000 chars text. Does Python support concatenations of __doc___ strings? Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Announcing FreeIPA v3.0.0 beta 2 Release
2012/8/17 Rob Crittenden rcrit...@redhat.com The FreeIPA team is proud to announce version FreeIPA v3.0.0 beta 2. Hi Rob, Regarding translations, I don't see yet a 3.0 branch on Transifex. Is it in the pipeline, so we could have time to work on translations for 3.0 GA? Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Announcing FreeIPA v3.0.0 beta 1 Release
2012/7/2 Rob Crittenden rcrit...@redhat.com The FreeIPA team is proud to announce version FreeIPA v3.0.0 beta 1. It can be downloaded from http://www.freeipa.org/page/**Downloadshttp://www.freeipa.org/page/Downloads . A build is available in the Fedora rawhide repositories or for Fedora 17 via the freeipa-devel repo on www.freeipa.org: http://freeipa.org/downloads/**freeipa-devel.repohttp://freeipa.org/downloads/freeipa-devel.repo. To install in Fedora 17 the updates-repo repository needs to be enabled as well. For additional information see the AD Trust design page http://freeipa.org/page/IPAv3_**AD_trusthttp://freeipa.org/page/IPAv3_AD_trustand the AD Trust testing page http://freeipa.org/page/IPAv3_**testing_AD_trusthttp://freeipa.org/page/IPAv3_testing_AD_trust . Wow! Dmitri told me last week in Boston that something was cooking, but I'm impressed at the changelog. Congrats to the team! Did you update transifex with the new strings for 3.0 for localization? Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About private ssh host keys in IPA
2012/6/5 Sigbjorn Lie sigbj...@nixtra.com On Fri, June 1, 2012 15:24, Simo Sorce wrote: This is about Ticket 1978 (originally rhbz746036). This RFE asks for storing private SSH Host Keys in FreeIPA. We have been triaging this ticket today, and I have to admit I am biased toward simply closing down the ticket. However we want to reach out community and interested parties that opened the tick to understand if there are reasons strong enough to consider implementing it. The reason I am against this is that in FreeIPA we already provide public Key integration. This means that when the host is re-installed new keys are loaded in IPA and clients do not get the obnoxious warning message that keys have changed, because enrolled clients (with the appropriate integration bits) trust FreeIPA so they do not need to ask the user to confirm on a key change. Storing Private Keys poses various liability issues, in order to be able to restore keys you need to give access to those keys to an admin, as there is no other way to authenticate just the host itself (it was just blown away and reinstalled). This means any admin account that can perform reinstalls need to have access to *read* private keys out of LDAP, which means that A) The central tenet of Asymetric authentication is that private keys are 'private'. B) keys are readable from LDAP to some accounts, any slight error in ACIs would risk exposing all private keys. C) most probably low level (junior admin) accounts will have read access to pretty much all private keys, because those admins are the one tasked with re-installs. However those admins are also the ones less trusted, yet by giving them access to private keys they are enabled to perform MITM attacks against pretty much any of the machines managed by FreeIPA. For these reasons I am against storing SSH Private Keys. I would like to know what are the reasons to instead implement this feature and the security considerations around those reasons. From my point of view the balance between feature vs security issues trips in disfavor of implementing the feature but I am willing to be convinced otherwise if there are good reasons to, and security issues can be properly addressed with some clever scheme. I think there has been some confusion here. What I was looking for was a way to prevent the users from receiving a message when ssh'ing into a host that's been reinstalled, that the host's key has changed. I believe will become availabe in the future version IPA 2.2 / RHEL 6.3? So what you're looking for is an automatic deployment of known_hosts in a centralised way (/etc/ssh) each time a new machine is deployed in an IPA domain ? Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About private ssh host keys in IPA
2012/6/1 JR Aquino jr.aqu...@citrix.com On Jun 1, 2012, at 6:35 AM, Stephen Gallagher sgall...@redhat.com wrote: On Fri, 2012-06-01 at 09:24 -0400, Simo Sorce wrote: This is about Ticket 1978 (originally rhbz746036). This RFE asks for storing private SSH Host Keys in FreeIPA. We have been triaging this ticket today, and I have to admit I am biased toward simply closing down the ticket. However we want to reach out community and interested parties that opened the tick to understand if there are reasons strong enough to consider implementing it. The reason I am against this is that in FreeIPA we already provide public Key integration. This means that when the host is re-installed new keys are loaded in IPA and clients do not get the obnoxious warning message that keys have changed, because enrolled clients (with the appropriate integration bits) trust FreeIPA so they do not need to ask the user to confirm on a key change. Storing Private Keys poses various liability issues, in order to be able to restore keys you need to give access to those keys to an admin, as there is no other way to authenticate just the host itself (it was just blown away and reinstalled). This means any admin account that can perform reinstalls need to have access to *read* private keys out of LDAP, which means that A) The central tenet of Asymetric authentication is that private keys are 'private'. B) keys are readable from LDAP to some accounts, any slight error in ACIs would risk exposing all private keys. C) most probably low level (junior admin) accounts will have read access to pretty much all private keys, because those admins are the one tasked with re-installs. However those admins are also the ones less trusted, yet by giving them access to private keys they are enabled to perform MITM attacks against pretty much any of the machines managed by FreeIPA. For these reasons I am against storing SSH Private Keys. I would like to know what are the reasons to instead implement this feature and the security considerations around those reasons. From my point of view the balance between feature vs security issues trips in disfavor of implementing the feature but I am willing to be convinced otherwise if there are good reasons to, and security issues can be properly addressed with some clever scheme. For the record, I am also in favor of just closing the ticket. It's much safer and wiser to require re-provisioning of the public key in the FreeIPA server than it is to try storing the private key. I suspect that when we had the original conversation on IRC, it was before we had decided that FreeIPA would be managing public keys. I am firmly against ever storing host private keys in a central location. +1 I am also for the public and against the private. +1 -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Please refresh Transifex pot file
Hi all, Still translating FreeIPA (although quarter/FY end impacts my pace here). As this is also a string freeze for F17, can you please upload the latest pot file to transifex so I can rely on a stable file to complete my translation ? Regards, thanks in advance, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Non easily translatable strings
Hi all, Going on on my translation to French for FreeIPA, it happens some strings will be difficult to translate, because they use non-named arguments. Here is the full list (search for \%s.*\%s in code or pot file) : ipalib/plugins/baseldap.py:1548 Search for %s with these %s %s. ipalib/plugins/baseldap.py:1549 Search for %s without these %s %s. ipalib/plugins/config.py:228 %s default attribute %s would not be allowed! ipalib/plugins/dns.py:1316 Delete %s '%s'? ipalib/plugins/dns.py:1331 %s record with value %s not found ipalib/plugins/sudorule.py:655 Added option %s to Sudo Rule %s ipalib/plugins/sudorule.py:710 Removed option %s from Sudo Rule %s ipa-client/ipa-join.c:746 Error parsing %s: %s.\n ipa-client/ipa-rmkeytab.c:230 ipa-client/ipa-rmkeytab.c:237 Failed to open keytab '%s': %s\n Do you want to handle it from here (I can code in Perl, but Python is cryptic to me), or do you want me to create a ticket ? Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA Italian translation
2012/1/8 Marco Pizzoli marco.pizz...@gmail.com Hi guys, I started to follow this mailing list only few time ago and I see there's a work in progress for language translations. If could be helpful, I would be glad to give my contribute to the Italian's one. I'm Italian mother tongue. Could someone give me a reference on what to do? Ciao Marco. The best way would be for you to : - review and follow processes setup by the Italian translation team for Fedora : https://fedoraproject.org/wiki/L10N_Italian_Team - get a login on Transifex - get a login on fas - get in teams - announce translation effort - translate. Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Translation to French for freeipa completed
2012/1/4 Jérôme Fenal jfe...@gmail.com 2012/1/4 John Dennis jden...@redhat.com On 01/04/2012 09:56 AM, Jérôme Fenal wrote: Thanks Dennis, I'll watch commits, and the subsequent update on Transifex (is this part automated ?). Yes, it's automated. Transifex watches our git repo and pulls the pot file whenever it is updated (or at least that's the way it's supposed to work, Transifex has been somewhat of a moving target :-) OK, thanks. Let's wait a day or two until Transifex does what it's supposed to do. Hi, Just a quick note to let you know that Transifex did update the .po. I'm back at 58% completion :( Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Translation to French for freeipa completed
2012/1/5 John Dennis jden...@redhat.com On 01/05/2012 04:32 AM, Jérôme Fenal wrote: Just a quick note to let you know that Transifex did update the .po. I'm back at 58% completion :( Jérôme everyone on the IPA team would like to thank you for helping us with the translation and wanted to express our regret some of your work was for naught due to an out of date pot file, please accept our apology. On our developer conference call this morning we put into place a policy to update the pot file once a month during active development (our current situation) and to have a string freeze prior to release. Hi John, No problem, this is the power of open source : continuous improvement of code (and processes). And I also could have wondered about the freshness of the pot file before... ;) Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Translation to French for freeipa completed
2012/1/4 John Dennis jden...@redhat.com On 01/02/2012 11:41 AM, Jérôme Fenal wrote: Hi all, I'm glad to announce that the French translation for FreeIPA software has been completed, as on Transifex, except for 21 strings related to entitlement.py. Given the recent developments, I'm not sure it is 100% up to date with current code. What is the policy regarding pushing updates to Transifex (strings freeze before pushing out a new release, or once in a while) ? Thank you Jérôme doing the translations, we very much appreciate it! The pot file on Transifex needs to be updated to a more current version and that update happens to be sitting in our patch queue waiting for a commit to our git repository. We expect the commit to occur today. We pull new po files from Transifex prior to new releases. We have been remiss by not have a formal string freeze in the past and announcing it, we do not want to make that mistake again and are going to add this to our release scheduling. Let me know if there is anything else I can help you with. Thanks Dennis, I'll watch commits, and the subsequent update on Transifex (is this part automated ?). Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Translation to French for freeipa completed
2012/1/4 Jérôme Fenal jfe...@gmail.com 2012/1/4 John Dennis jden...@redhat.com On 01/02/2012 11:41 AM, Jérôme Fenal wrote: Hi all, I'm glad to announce that the French translation for FreeIPA software has been completed, as on Transifex, except for 21 strings related to entitlement.py. Given the recent developments, I'm not sure it is 100% up to date with current code. What is the policy regarding pushing updates to Transifex (strings freeze before pushing out a new release, or once in a while) ? Thank you Jérôme doing the translations, we very much appreciate it! The pot file on Transifex needs to be updated to a more current version and that update happens to be sitting in our patch queue waiting for a commit to our git repository. We expect the commit to occur today. We pull new po files from Transifex prior to new releases. We have been remiss by not have a formal string freeze in the past and announcing it, we do not want to make that mistake again and are going to add this to our release scheduling. Let me know if there is anything else I can help you with. Thanks Dennis Well, I meant : Thanks John... -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Translation to French for freeipa completed
2012/1/4 John Dennis jden...@redhat.com On 01/04/2012 09:56 AM, Jérôme Fenal wrote: Thanks Dennis, I'll watch commits, and the subsequent update on Transifex (is this part automated ?). Yes, it's automated. Transifex watches our git repo and pulls the pot file whenever it is updated (or at least that's the way it's supposed to work, Transifex has been somewhat of a moving target :-) OK, thanks. Let's wait a day or two until Transifex does what it's supposed to do. Regards, Jérôme -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Translation to French for freeipa completed
Hi all, I'm glad to announce that the French translation for FreeIPA software has been completed, as on Transifex, except for 21 strings related to entitlement.py. Given the recent developments, I'm not sure it is 100% up to date with current code. What is the policy regarding pushing updates to Transifex (strings freeze before pushing out a new release, or once in a while) ? Regards, thanks in advance, Jérôme -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py
diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py index bdca3ec..d01791b 100644 --- a/ipalib/plugins/role.py +++ b/ipalib/plugins/role.py @@ -45,7 +45,7 @@ EXAMPLES: Add some privileges to this role: ipa role-add-privilege --privileges=addusers junioradmin ipa role-add-privilege --privileges=change_password junioradmin - ipa role-add-privilege --privileges=add_user_to_default_group juioradmin + ipa role-add-privilege --privileges=add_user_to_default_group junioradmin Add a group of users to this role: ipa group-add --desc=User admins useradmins -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py index bdca3ec..d01791b 100644 --- a/ipalib/plugins/role.py +++ b/ipalib/plugins/role.py @@ -45,7 +45,7 @@ EXAMPLES: Add some privileges to this role: ipa role-add-privilege --privileges=addusers junioradmin ipa role-add-privilege --privileges=change_password junioradmin - ipa role-add-privilege --privileges=add_user_to_default_group juioradmin + ipa role-add-privilege --privileges=add_user_to_default_group junioradmin Add a group of users to this role: ipa group-add --desc=User admins useradmins ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py (2)
diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py --- a/ipalib/plugins/role.py +++ b/ipalib/plugins/role.py @@ -54,7 +54,7 @@ EXAMPLES: Display information about a role: ipa role-show junioradmin - The result of this is that any users in the group 'useradmins' can + The result of this is that any users in the group 'junioradmin' can add users, reset passwords or add a user to the default IPA user group. ) -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py --- a/ipalib/plugins/role.py +++ b/ipalib/plugins/role.py @@ -54,7 +54,7 @@ EXAMPLES: Display information about a role: ipa role-show junioradmin - The result of this is that any users in the group 'useradmins' can + The result of this is that any users in the group 'junioradmin' can add users, reset passwords or add a user to the default IPA user group. ) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Another trivial doc fix
diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index cd4a054..4bf77f8 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -28,8 +28,8 @@ Groups of users Manage groups of users. By default, new groups are POSIX groups. You can add the --nonposix option to the group-add command to mark a new group -as non-POSIX, and you can use the same argument to the group-mod command -to convert a non-POSIX group to a POSIX group. POSIX groups cannot be +as non-POSIX. You can use the --posix argument to the group-mod command +to convert a non-POSIX group into a POSIX group. POSIX groups cannot be converted to non-POSIX groups. Every group must have a description. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA documentation source on Transifex ?
Hi all, Are there plans to push the documentation source (docbook, I guess) on Transifex ? That would help to initiate a translation effort (French being my target here). Regards, J. -- Jérôme Fenal - jfe...@gmail.com - jfe...@redhat.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] fix copy/paste
Hi all, A trivial patch found during French translation : diff --git a/ipalib/plugins/aci.py b/ipalib/plugins/aci.py index fc5582d..429ae6e 100644 --- a/ipalib/plugins/aci.py +++ b/ipalib/plugins/aci.py @@ -543,7 +543,7 @@ class aci_del(crud.Delete): Execute the aci-delete operation. -:param aciname: The name of the ACI being added. +:param aciname: The name of the ACI being deleted. :param kw: unused assert 'aciname' not in kw Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
