Re: [puppet] Sign up for transifex error notifications.
On Sat, Jun 27, 2009 at 6:34 PM, Toshio Kuratomia.bad...@gmail.com wrote:
Should we set this to send messages to an admin wide alias?
fedora-infrastructure-list might be a little broad but
ad...@fedoraproject.org or something?
Probably yes. They're Python exception (500) errors.
404 errors are only sent to the MANAGERS variable (we can safely
remove admin@ from this setting).
-d
---
diff --git a/modules/transifex/templates/00-default.conf.erb
b/modules/transifex/templates/00-default.conf.erb
index fa7ad88..172c750 100644
--- a/modules/transifex/templates/00-default.conf.erb
+++ b/modules/transifex/templates/00-default.conf.erb
@@ -23,6 +23,7 @@ ADMINS = (
('Diego Burigo Zacarao', 'dieg...@gmail.com'),
('Dimitris Glezos', 'dimit...@glezos.com'),
('Ignacio Vazquez-Abrams', 'ivazquez...@gmail.com'),
+ ('Ricky Zhou', 'ri...@fedoraproject.org'),
)
MANAGERS = ADMINS
-Toshio
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
--
Dimitris Glezos
Founder and Chief Engineer, Indifex
Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Translation Toolchain Freeze
In Fedora's 6-month cycle, there are a few weeks in which translators are working full-steam. These are the period for software translation and one for Docs translations. During these periods the L10n Infrastructure should be considered frozen, otherwise the work of a few hundred people will be interrupted (currently 40+ commits per day are taking place). Looking at poelstra's schedule [1], these freeze periods are: 2009-03-10 - 2009-04-14 2009-04-29 - 2009-05-14 If there's a document we need to have these added, please let me know. Having the same process (+1s etc) for L10n Infra would be great, IMO. -d [1] http://poelstra.fedorapeople.org/schedules/f-11/f-11-trans-tasks.html -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Request] Transifex 0.5.1
2009/3/29 Diego Búrigo Zacarão dieg...@gmail.com: Can we have +1's to update Tx on app1? It's only a maintenance release and should not break anything. The changes can be found in the release notes: http://docs.transifex.org/releases/0.5.html#transifex-0-5-1-aurora -d -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Infrastructure freeze breakage request: Banner from DL linking to new Transifex
On Wed, Mar 25, 2009 at 7:13 AM, Asgeir Frimannsson asge...@redhat.com wrote: - Mike McGrath mmcgr...@redhat.com wrote: On Tue, 24 Mar 2009, Asgeir Frimannsson wrote: Hi folks, Can I get an ack or two to commit a change in the Damned Lies CVS repository that adds a banner to the top of each page with the following content: These pages are served by Damned Lies. You can now use a href=https://translate.fedoraproject.org/tx/;Transifex/a for all your translation needs, including viewing Translation Statistics, as well as downloading and committing translations. There might be better ways of saying this - but I'm not in creative-mode today, suggestions welcome :-) Patch follows below. +1 from me on the condition that the translation team know's its coming. I'd assumed they have started using tx but not being a translator I guess I don't know for sure :) Thanks, all done now :-) Yes, the team should know this is coming by now. Having the banner on the page does make the transition a bit smoother when we finally move transifex from /tx/ to / after the freeze. I've also hot-fixed such a banner in the old Tx instance at https://translate.fedoraproject.org/submit/ -d -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: sanity request
On Thu, Mar 12, 2009 at 3:27 AM, Mike McGrath mmcgr...@redhat.com wrote: On Wed, 11 Mar 2009, Jesse Keating wrote: One thing I think we could do is do more of what mmcgrath just did, posting the proposed change as a diff. As long as it isn't sensitive info, we can just use the git send-email program to send the commit we'd like to push to this list, using --compose to allow us to compose a message that the patch will be in reply to. That'll give the subject some context, the email body the actual change and some sanity to the whole thing (: Huh? git can do that? :) There's also git make-coffee. -δ -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
change request
Deployment of tx to app1 brought some more issues on the surface. We'd like to install a new tx RPM. It doesn't bring any new deps in, just fixes a few inner workings and DB tweaks. +1/-1s? -d PS: Hoping these change requests won't be many more. :/ -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Reviewers needed: Packaging Transifex
Our goal about Fedora 11 translations is have Transifex on our production servers by March 10th. We're packaging it in yum to make things as easy as possible for the Infrastructure team. Transifex's dependencies are in desperate need for some reviewers. https://bugzilla.redhat.com/show_bug.cgi?id=488151 -d -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Plan for L10n for Fedora 11
I'm very happy to announce that we've now landed support for translation statistics in Transifex. Lately we've been working heavily in re-writing Transifex and getting v0.5 in the best shape possible for Fedora 11. Being 3 weeks ahead of the string freeze, we have plenty of time to test statistics on Transifex 0.5-devel. For Fedora 11, my plan is to switch the old DL for Tx 0.5-devel for statistics, and continue to use the proven Tx 0.3 for submissions. I've requested [1] a publictest instance from the Infrastructure Group to install it and start putting data and testing it. [1]: https://fedorahosted.org/fedora-infrastructure/ticket/1191 To allow 2 weeks of testing, the instance should be ready by 23/2. When we see that everything works out as it should, we can discontinue the old DL. Our goal with Transifex 0.5 is to include support for both submissions and statistics, and this way we can put aside our old version of Damned Lies which is presenting outdated translations. Since only the commits are missing from Tx 0.5-final, it'll be out in 3-4 weeks, and at that point we go on and test submissions too, while having Tx 0.3 as a backup solution. Some of the advantages of this approach is that using the statistics from Tx 0.5-devel does not even require hook-up with FAS (only submissions require authentication), we have a smoother upgrade path for Django/v0.5 and we have a codebase we know inside-out to build/invest on. On our roadmap post v0.5: - 0.5: Submissions to email,VCSs, probably bugzilla - Comments everywhere - Full API - Integration with Bugzilla eg. for auto-closing of bugs - Workflow functionality (lock a file, resolve bugs, request translation review and others, comments) - Fine-grained permissions on a per collection, release, projects, component, language and file basis - Support for people Teams and user groups - Support for additional i18n formats (mozilla) Comments, suggestions? -δ -- Dimitris Glezos Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Planning a future L10N infrastructure (including Fedora)
2008/9/17 Asgeir Frimannsson [EMAIL PROTECTED]: On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote: Please correct me if I'm reading this wrong but I see transifex is great or close to it and here's how we're going to build our own solution anyway ? Yes, Transifex is great and will continue to serve us. BUT: If you look at the state of the art in L10N outside the typical Linux projects where PO and Gettext rule, you'll notice we are very short on areas like: - Translation Reuse - Terminology Management - Translation Workflow and Project Management - Integration with CMSs. - Richer Translation Tools This is an effort in narrowing that gap, and I can't see that effort work by evolving an existing tool from this 'cultural background'. Yes, we can get some of the way by developing custom solutions for e.g. linking wikis to Transifex for CMS integration, or using e.g. Pootle for web-based translation. But we would still be limited to the core architecture of the intent of the original developers, which is something that would radically slow the project down. For the record, I believe these are some fine ideas, which I would like to see added to Transifex as features (eg. through plugins). I have been discussing most of them with people around conferences for the past year. An example: Tx already downloaded all the translation files from upstream projects, so if someone requests a translation file, why not be able to pre-populate it using existing translations from all the other projects (translation reuse)? Also, I should mention that Transifex isn't (and will never be) specific to a particular translation file format (eg. PO) or any translation repository. I'd like to support translation of both PO and XLIFF files. And also support not only VCSs, but CMSs, wiki pages and even arbitrary chunks of text. Transifex's goal is to be a platform to help you manage your translations. Correct me if I'm wrong though, instead of forking or adapting or working with upstream, you are talking about doing your own thing right? We have a goal of where we want to see L10N infrastructure go, to enable us in the future to provide internal (translators paid by Red Hat) and community translators with tools to increase their productivity as well as better tools to manage the overall L10N process. If there is an 'upstream' that provides this, or a platform on to which we could develop this, then yes, we would consider 'working with upstream' or (in a worst-case-scenario) forking upstream. The Translate Toolkit folks are a very friendly bunch, actively maintaining and extending the rich library, and always open to suggestions. Maybe some (if not all) of the features could be done in TT, and the rest that might not fit there, as Python libraries to maximize interoperability and community involvement. I also think that Transifex could serve as the UI for a lot of translation-specific tasks. If there's a library that does X, that would help people manage their translations or leverage Transifex's strong points of I read a lot of repositories and I write to some repositories, then we could provide a web wrapper around it. (eg. search for string X in all translation files of language Y, or mark this file as a downstream of that and send me an msgmerged file whenever that changes. So to answer your question bluntly, YES - after 4 years involvement in industry and community L10N processes - I believe we can do better. But holding that thought, remember that this is in many ways 'middleware', and making use of e.g. the vast amount of knowledge invested in Translate Toolkit (file format conversions, build tools, QA) makes sense, and I'm not saying 'forget about all that we have invested in tools so far'. It might be my poor English or the fact that I usually read long mails at night, but despite the lengthy descriptions I still don't have a clear picture of exactly what problem you'd like to solve, and the reasoning behind the decisions being made. Don't take me wrong -- I think there are some good ideas. But I feel it would be too bad if you guys didn't invest on top of existing tools (TT for file formats, Transifex for file operations and UI, OmegaT for translation memory) or just isolate specific solutionsthat don't fit into other projects in well-defined libraries (do one thing, to it right). Sure, it takes a lot more effort to work *with* other people, but it is usually worth it. :-) -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora and CIA.vc
I think this was discussed briefly in the past on IRC, having Fedora listed on http://cia.vc/. CIA is a real-time window into the open source world, providing Real-time open source activity stats with active projects, people, commits, etc. It probably won't provide much added functionality (although its RSS feeds are handy sometimes eg. [1]), but it'd be good having Fedora on another contributor/project map. And with the diversity of the projects hosted on Fedora Hosted, maybe this will bring more contributors in. We'll need to add the CIA client script to our versioning systems: http://cia.vc/doc/clients/ -d [1]: http://cia.vc/stats/project/kde/amarok -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Rename cvsextras during FAS2 switch?
On Mon, Mar 10, 2008 at 7:18 AM, Warren Togami [EMAIL PROTECTED] wrote: Hi folks, I am wondering, might it be a good time to s/cvsextras/packager/ during the move to FAS2? It might be an opportune time because everything will be down anyway? I am just afraid if we don't do it now we might still have it a year from now. =) Same for cvsl10n to l10n/translator. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Problem commiting to the new CVs repository for libvirt localization
On Sat, Feb 23, 2008 at 12:04 PM, Daniel Veillard [EMAIL PROTECTED] wrote: Note that there is still a small problem though: paphio:~/i18n/libvirt - cvs -z9 commit cvs commit: Examining . Access allowed: veillard is in ACL for libvirt. Checking in libvirt.pot; /cvs/elvis/libvirt/libvirt.pot,v -- libvirt.pot new revision: 1.25; previous revision: 1.24 done cvs commit: warning: cannot write to history file /cvs/elvis/CVSROOT/history: Permission denied paphio:~/i18n/libvirt - This should be fixed now and translations through Transifex succeed. FYI, we disabled the PO checking completely, since Tx supports pre- and post- hooks and is already implementing a pre-commit check for a PO file's syntax validity. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Securing our transifex instance
Hi all. It's time to add some non-localhost repos to our transifex instance, so some advices on the security front would be greatly appreciated. We're doing everything over SSH, with encrypted keys. Before starting the TG app, tha admin needs to run ssh-agent and ssh-add. The goal would be to have a different service actually handling the keys and the commits, but that would have to wait for someone to submit the patchset. With each repository (host) having its own key pair, `~/.ssh/config` right now looks like this: Host localhost User transifex-testuser IdentityFile ~/.ssh/id_dsa #Host cvs.fedoraproject.org # User transifex # IdentityFile ~/.ssh/id_dsa-cvsfpo Host repo.or.cz User yumex-trans IdentityFile ~/.ssh/id_dsa-yumex Host * ForwardX11 no ForwardAgent no RhostsAuthentication no RhostsRSAAuthentication no PasswordAuthentication no StrictHostKeyChecking yes BatchMode yes CheckHostIP yes On the web front, I tried my best to validate properly any input/output from/to the user. Since transifex accepts user input, writes files on our server, runs OS commands on the server, uses SSH keys to communicate with other machines and writes to disks across the Internet, we better make sure everything is OK before launching. It would be great if some of you python hackers take a look at the code, or anyone with the hobby of defacing websites run any injection/XSS-foo on our instance, in order to identify and any additional checks or reveal any mistakes I made (which I'm sure I did since it's my first big python and TG app). Our test instance dwells at http://publictest5.fedora.redhat.com/submit/ Short instructions to get the code and install a local instance to play around freely and with less lag can be found at: https://hosted.fedoraproject.org/projects/transifex/browser/INSTALL Bugs, reports, suggestions: https://hosted.fedoraproject.org/projects/transifex/newticket Thanks. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: wikidbase
O/H seth vidal έγραψε: reading rss feeds last night - I think this is something we could use eventually: http://www.nickblundell.org.uk/projects/wikidbase/overview/ I realize it's using django - but if there's something like it for turbogears I'd be all ears. A simple way of letting an end user dynamically create a database and automatically have the web forms to go with it would go a long way for a lot of things we'd want to record. Definitely looks interesting. Q: How difficult would it be to start using django apps on our Infra -- what spaces do we need to fill and how difficult would it be? -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
domain list
We are trying to collect all the domains we are maintaining at the following wiki page: http://fedoraproject.org/wiki/Websites/DomainsList The purpose is to use Google Webmaster Tools (or any other tool) to track down our 404s, redirects, search strings, etc. Please add any domain/system you know we have. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Python, VCSs, ssh keys and Transifex
O/H Karsten Wade έγραψε:
On Sat, 2007-07-14 at 00:55 +0200, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
This is my worry too. It's almost enough to make me not want to do it
for non Fedora projects but thats just bad. I'm hoping someone here has
a good, clever way to solve this issue.
The benefits of these new tools far outweigh the relatively slight
risks. We really must step up and find a way to make it work.
My vote is simple: we do the best we can, we spell out what the
security is and the risks involved, and we put that in front of upstream
projects. We ask them to agree (via email?) to the risk/reward balance
we present. [...]
Security risk assessment is never about, No matter the cost, I will
secure this until it is unbreakable. That guarantee comes from a pair
of wire cutters used on the CAT(5) between the server and the switch.
Great for security, bad for business. [...]
Remember, a risk assessment has to balance the rewards.
In this case, the rewards are ENORMOUS:
* Anyone notice how translate.fedoraproject.org and transifex have just
solved in six weeks many of the complaints people have about Launchpad
and Rosetta?
* Do we think upstream projects are going to want the ability to add an
army of translators?
Full disclosure of the security measures in place should be enough for
upstream to decide if the rewards are worth the risk.
Karsten pretty much summarized all my thoughts on the whole idea of transifex.
Thanks mate. :)
I plan to start by directly using `~/.ssh/` and one key for all remote repos. If
it's not hard to do multiple keys (I think it isn't) via `.config`, then cool.
For starters, we can try it out with {cvs, hg, git}.fpo. And i18n.redhat.com if
the folks behind it want to be part of this.
This will give us a proof-of-concept implementation and will help us document
the procedure and understand what more we can do in the area of security and
usability. Then I'd be happily accepting any patches to add more layers of
security, like eg.:
* Adding SELinux to protect the keys
* Moving `.ssh` out of `~/`
* Creating a new program/daemon to handle the VCS transactions
And some more high-level controls that could bump the system's trust:
* Add editors (eg. lang maintainers) who only them could push the changes after
reviewing them
* Publish local repos to add the choice for a maintainer to pull the
translations instead for transifex to push them to the main repo
-d
--
Dimitris Glezos
Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B
http://dimitris.glezos.com/
He who gives up functionality for ease of use
loses both and deserves neither. (Anonymous)
--
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Python, VCSs, ssh keys and Transifex
Hi all. There is a darkish cloud of security uncertainty in my sky (and Fedora's!), so it's better to discuss this as early as possible to avoid any late notices. I'm working on a web app that will help translation submission by allowing fedora translators (members of cvsl10n group) to commit translations to systems they don't have direct access to. Think: hosted.fpo (svn/hg/git). https://hosted.fedoraproject.org/projects/transifex The idea is that transifex will act as a proxy/mediator for translation commits. A translator will login to the transifex instance running on a host like `translate.fpo`, choose a module, a PO file to upload, and a destination file and click submit. The system will commit the file for him. Underneath this is achieved by having the VCS admin create a user (eg. fedora-transifex) with a dedicated SSH key, and give it write access to the specific modules accepting translations. The transifex admin will then hook the repo and module up with the system. Each commit will be done by the fedora-transifex user, and the actual user's details (name, surname, email, fedora username) will be written in the commit message and Changelog file. Transifex supports filaname filters, so even if a module maintainer can't add ACLs to the repo, he can define them on the transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$). To put things in perspective, if we do this *right*, then *any* remote VCS could be hooked up. In the future, we could add a layer of approval before commits, so that the language maintainer (which we probably trust more than a john doe user with cvsl10n access) approves queued messages to be pushed. Or, we could give the option to a dev (for DVCS) to pull instead of the webapp to push. To the implementation details now, transifex will become the client to the remote VCSs. Once the user clicks submit PO, the webapp should commit (and push). The security question is how do we handle SSH keys? - Where do we store them? Best place would be ~/.ssh/, because not all VCS commands support SSH options to point to a different config file. - Right before running the checkout/pull and checkin/push commands, the environment should be right so that the commands run by the webapp will succeed over SSH. So an option the webapp (just like anyone) will have to type the passphrase to unlock the key. Or, use ssh-agent. And probably SELinux. What's the best approach with the minimum compromise risk? - Where are we going to actually store the keys and passphrase? On-disk or in the DB? If we store them encrypted, where do we store the salt? - Do we need a different process running that handles these security requests? Seeking the knowledge and experience of the wise, the humble developer comes to you with seriously cold feet. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Wiki localization: patch wiki, or work with current tools ?
O/H Paulo Santos έγραψε: Here is my suggestion for the time being... We will need to add this for each language that its fully translated in the wiki FWIW, our wiki *does* support localization through simple Language dictionaries. See: http://fedoraproject.org/wiki/FrenchDict At a point you can spot: FedoraMain :: fr_FR/FedoraPrincipal That line is used to automatically redirect a french browser to the french main page of the wiki. Our concern is how to present a language box for each page, showing links to the other versions of the same page. This is somewhat the opposite of the above language-based method, and would require for each page reload to scan all language dictionaries and present only those that have the dictionary entry for the particular page. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Moin 1.6 and 1.7
O/H Paulo Santos έγραψε: Personally i would go for 1.7, since im sure that noone will want to maintain their own moin branch, and keep patching it manually without breaking the rest of the new patches. Working with upstream 1.7 sounds more sane. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
L10n web infrastructure
Hey guys. We've got our L10N GSoC project started, so we'll be needing a place to put 'l10n.fedoraproject.org' soon. Basically, we'll put a python Web UI up there first, and then start experimenting to use it as an intermediate to fetch PO files from remote SCMs to members of the 'cvsl10n' group. There's an RFR open for it: http://fedoraproject.org/wiki/Infrastructure/RFR/L10nCVSandUI The python thingy is GNOME's Damned Lies, and requires either SQLite or MySQL. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: fedorapeople (planet and .org)
O/H seth vidal έγραψε: Hey folks, So we've been thinking we're going to take fpserv.fedoraproject.org which lives at duke and make it into fedorapeople.org and also planet.fedoraproject.org fedorapeople.org will provide all the fedora account holders and groups with some quota-controlled space to put files up. what I was thinking might be cool is to reinstall fpserv with el5 so we can use Xen. Then setup 2 xen guests. 1 would be the system that people use to put their files up, the other would be for the planet code that makes the planet pages (planet.fedoraproject.org, etc) Does that sound pretty good to everyone? Sounds great Seth. It will help a lot for various files we need to upload now and then which now lie either on personal servers, redhat.com space or the wiki. Looking forward to it! Any compelling reason not to use the 'people.fedoraproject.org/user/' URL structure instead of 'user.fedorapeople.org'? I'm just worried we'll begin to get lost with all these subdomains and miss the handy 'host:fedoraproject.org' google search query. Not to mention the URL auto-complete of most browsers. :) -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: cvsl10n CVSROOT (RFR)
O/H Karsten Wade έγραψε: On Tue, 2007-03-13 at 17:34 -0400, Bill Nottingham wrote: Dimitris Glezos ([EMAIL PROTECTED]) said: Our translators have made it clear they want to use a SCM for the translations and said an *additional* web-based tool would be nice. So, let's first create our SCM and we'll see about whether we should use pootle. Use *one* SCM. How to gate currently hosted GIT/HG/etc into this is unclear. :/ A first iteration at a solution could look like this: * Projects, regardless of SCM, generate POT file and use WUI or CLI to schedule pick-up of their POT into l10n.fp.o * l10n.fp.o has a WUI that sits in front of 1 SCM and has the ability to: - Translate through the WUI (download POT, upload PO) - Use one account (FAS) for all access (regardless of back-end SCM, it needs a *l10n group that all L10N members are within) - Provide statistics across all SCMs * For translators who want to use the CLI entirely for translations, they need to work directly with the SCM, however ... Note that I suggest a CLI for access to the same services the WUI is providing. The idea here would be to grow a CLI (fedoral10n?) that acts like the WUI - it interacts with 1 back-end SCM, uses FAS for auth+, etc. So, first feature of the fedoral10n CLI would be for developers (and scripts) to automate the management of POT/PO files. Second feature would be to give translators equivalent control that the WUI provides. So, we've got two issues with L10N: 1. Enabling proper ACLs on CVS 2. The Web User Interface Mike is working on the first. An RFR for this has been opened at: http://fedoraproject.org/wiki/Infrastructure/RFR/L10nCVSandUI -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: cvsl10n CVSROOT
O/H Mike McGrath έγραψε: Dimitris Glezos wrote: O/H Karsten Wade έγραψε: For Paul, Dimitris, and others ... Mike and I were discussing CVS structure for cvsl10n. These are configuration choices for e.g. CVSROOT, and etc. Goals: * R/W for the po/ directory in documentation modules (/cvs/docs/.../po) * Same for po/ under any merged packages ( Extras), although for the most part those are projects that should have translation upstream * Pull in sample content from elvis.rh.c:/usr/local/CVS - part of planning to be able to copy all content and switch Here is a *test* import of the existing L10N CVS -- note that this content may get removed at any time, and people in the cvsl10n have write access to it: http://cvs.fedoraproject.org/viewcvs/?root=l10n Sounds OK to me. What's the next plan? Some more ideas/food for thought: We could have virtual folders like we do on i18n.r.c: a translator does a `cvs co translate` there (`cvs co l10n` in our system) and receives something like: anaconda/ af.po am.po anaconda.pot ... apacheconf/ af.po ... Also, our TODO should somewhere include automerge: each time a new POT file is committed the PO files could be automatically updated (currently not supported at i18n.r.c but is in the TODO list there too). Finally, since we're at it, we should probably start making plans for http://l10n.fedoraproject.org/. A *great* example is http://l10n.gnome.org/. This is probably the only tool the L10N community needs (although the job can be done locally too). Any help from the TurboGears experienced folks in Infrastructure would be greatly appreciated. :) You know more about the translations needs then I do. Paul had also mentioned http://translate.sourceforge.net/; as an option. On the one hand I'd be fine if we wrote our own app in turbogears. On the other hand, I'd love to use something already out there. Let me see what I can do about the modules and the po files. See below, after the short explanations. And just for the education of myself and those on the list. Can you tell us the difference between l10n and i18n is, and how you guys do what you do, what the heck a po or pot file is. Just educate us in general about your needs and how cvs.fedoraproject.org will help you accomplish them. In short: * i18n: Making something *able* to be localized, ie develop baring in mind that it should be localizable. That might mean, for example, to use gettext to print stuff, not assume everybody uses am/pm for time etc. * l10n: Making a product local. Translating strings, make sure encodings work, have proper fonts, keyboard layouts, adopt cultural values, local customs etc. It is the complementary process of i18n: it takes place after it. Basically, the distinction is subtle but we can simply talk about L10N to keep things clear. * POT: A specially-formatted file that contains every string the software has that should be localized (translated). Example: 'anaconda/anaconda.pot'. Example 2: Docs project uses xml2po to grab XML strings and produce POT files. * PO: A one-to-one translation for every string in the POT file. Example: 'anaconda/de.po' holds the german translations of anaconda. A translator initially copies the POT file to 'de.po' and uses tools like kbabel and gtranslator. ## i18n l10n process * The maintainer creates his product with i18n in mind. She freezes the strings, exports strings in the POT file and tells L10N folks to go on and translate. When the translation freeze comes, he grabs the PO files back and produces localized versions of the application. For software, that means she compiles them into binary MO files and packages the app. For Docs, we just create HTML versions with the translated strings/images in them. * The translators use the POT file to create or update their PO file (using `cp` for the first and `msgmerge` for the second). They then commit the PO file back to the maintainer (either with email or with the project's SCM). Because of the many PO files and their frequent updates, a project usually helps translators by having a web-based statistics page that shows the percentage of translation for each PO file (application, component) for each language. An answer for the question Why move? can be found on [1]. [1]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure#WhyMigrate ## L10N statistics You can see the existing Fedora (Red Hat) translation statistics page at [2] (yes, it should be called l10n-status). The GNOME L10n portal can be found at [3] and the KDE one at [4]. [2]: http://i18n.redhat.com/cgi-bin/i18n-status [3]: http://l10n.gnome.org/ [4]: http://l10n.kde.org/ We want (and need) to create something similar to the above. It is not really urgent though, since translators can see their translation stats locally from their command line. ## The translate toolkit It is basically a set of tools
Re: RecentChanages error
O/H Dimitris Glezos έγραψε: We've got an error on: http://fedoraproject.org/wiki/RecentChanges ValueError invalid literal for long(): not needed any more Oops. Sorry for the double post after tchung's one. And this triple one. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Infrastructure Design - Look Feel
O/H Máirín Duffy έγραψε: [...] I heard that you folks are building a bunch of infrastructure applications and would like them to have a consistent look and feel, and I would be very interested in helping out in this effort. I have a couple of questions about the project: [...] Based off of these I think the next steps would be for me and maybe some other designers (I will try to recruit some :) ) Máirín, first of all, kudos for the initiative! I'd be glad to help you out in this process. This has been on my mind too but unfortunately haven't had the time to drive it. I did some very minor wiki design tweaks [1] which hopefully will be included in the wiki upgrade on the 21th. -d [1]: http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
