L10N and I18N Installation Test Day Tomorrow
by Igor Pires Soares
Greetings everyone!
Remember that tomorrow (2011-03-01) we will host a Localization and
Internationalization Installation Test Day [1]. This test day will focus
on translations quality for Anaconda and i18n support during
installation as well as some post install verification tests.
Fell free to edit the wiki with your results and join us in
#fedora-test-day if you have any doubts.
I'm looking forward to see the participation of many translators around
the world. A wider language diversity will be great for making sure that
Fedora 15 will have a proper l10n/i18n support for everyone.
[1]
https://fedoraproject.org/wiki/Test_Day:2011-03-01_L10n_i18n_Installation
Regards,
--
Igor Pires Soares
Fedora I18N/L10N QA
Fedora Ambassador (Brazil) - Member of FAmSCo
https://fedoraproject.org/wiki/User:Igor
13 years, 2 months
Schedule for migration to transifex.net
by Göran Uddeborg
This is not meant to put even more pressure on system administrators
that I'm sure are already too busy. But may I ask if I could get an
estimate of when new language groups in Transifex can be expected? It
is around a week since I requested a Swedish group.
Again, I understand that there is much to do, and a week isn't a long
time to do it all. But at the same time, the translation deadline is
only two weeks away, which is making me a bit nervous.
13 years, 2 months
Re: Adding currency symbol in indian locale
by pravin.d.s＠gmail.com
created patch for this http://pravins.fedorapeople.org/bug-678216.patch
simply updated currency_symbol to <U20B9> i.e. ₹
As far as i know all locale must use <U20B9> but let me know if there is any
exception
-
Pravin S
On 24 February 2011 13:29, pravin.d.s(a)gmail.com <pravin.d.s(a)gmail.com>wrote:
>
>
> On 24 February 2011 13:17, Ankitkumar Rameshchandra Patel <
> ankit(a)redhat.com> wrote:
>
>>
>> It's perfectly fine to put the currency symbol in all Indic locales.
>>
>> However, if you could do it via filing a bug upstream, would be great.
>>
>
> Yes, we do have fedora bug
> https://bugzilla.redhat.com/show_bug.cgi?id=678216
> I will report bug upstream as well and submit patch there
>
> -
> Pravin S
>
>
>
13 years, 2 months
Transifex.net migration may lead to loss of our copyright headers
by Ville-Pekka Vainio
Hi all,
It was brought to our attention by a Mageia translator on #fedora-l10n
today, that the new version of Transifex does not leave the copyright
headers in po files intact.
For example, if I download the Finnish translation of Anaconda from
http://www.transifex.net/projects/p/anaconda/resource/master/ , the po
file header contains:
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR Red Hat, Inc.
# This file is distributed under the same license as the PACKAGE
package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
Whereas in
https://translate.fedoraproject.org/projects/p/anaconda/c/f14-branch/view... the po file has five lines of copyright information, the oldest being from 1998.
In my opinion, losing the headers is a big problem, both from the
copyright standpoint and from the "reputation" standpoint. Most people
work on the translations for free and the having their name attached to
the work they've done is one of the few rewards they get.
--
Ville-Pekka Vainio
13 years, 2 months
Re: L10N migration to transifex.net
by Runa Bhattacharjee
[top-posting to retain the quoted mail in entirety]
Thank you Toshio for the detailed information. This does provide some clarity
about the events in the background that eventually led to the decision. Since we
are already into the transition phase, further debate on the 'hows' and 'whys'
and 'so thats what it really was' would not serve much purpose besides adding to
the noise.
However, since we do expect to review the decision and explore the possibility
of returning to a Fedora hosted infrastructure, we may as well ensure that we do
not repeat the mistakes, especially that of communicating. As opposed to the
individuals from the FLP, the FLSCo, an elected group of representatives from
the FLP did not seem to figure anywhere during all this (unreported) discussion.
As a result, an established communication channel within the FLP was completely
ignored or not utilized.
The 'threat board' is perhaps another good thing to have in the future. With red
signs flashing all over the FLSCo and FLP could have pushed for discussion much
earlier. It would also allow individual project teams to check back on the
general health of the tools that they use.
Thank you for your patience and hopefully we can see a much stable translation
infrastructure in place for the FLP.
regards
Runa
On শুক্রবার 25 ফেব্রুয়ারি 2011 06:14 , Toshio Kuratomi wrote:
> On Thu, Feb 24, 2011 at 02:08:40PM -0800, Karsten Wade wrote:
>>
>> Definitely there was some process breakdown and some lack-of-process.
>>
>> It seems that it wasn't an active open community discussion between
>> Infrastructure and affected teams about problems with maintaining
>> translate.fp.org and how to fix them. This all could have been discussed
>> over the preceding months, presuming that were possible ... and I am going
>> to presume it wasn't, that we are here based on a series of best-efforts
>> and best-will from people involved. Does that make sense?
>>
> So... you'll need to contact mmcgrath for exactly where, with whom, and when
> previous discussions took place but discussion had been taking place for
> quite a while. A lot of people realized there was an issue when this ticket
> took 9 months to resolve:
> https://fedorahosted.org/fedora-infrastructure/ticket/1455
>
> Enough that gomix, beckerde, other translators, and I discussed the situation
> at FUDCon Chile last year and I opened this ticket:
> https://fedorahosted.org/fedora-infrastructure/ticket/2277
>
> The first meeting that we (infra) discussed that ticket at, mmcgrath said
> that he'd tried but failed to find someone to maintain transifex in infra
> from the l10n team. He and I tried to think of someone that we knew
> personally that could do the job and via email got in touch with beckerde who
> agreed to work on packaging and migration of the new transifex.
>
> Since beckerde was new to Fedora packaging and transifex dependencies had
> changed it took a while to get things working but with the help of other
> latam packagers we got packaging sorted out eventually and started to test
> upgrades on the infrastructure staging servers. The version that's being
> worked on is an older version because newer versions of transifex would
> change the translation workflow (the recent talks have made clear that the
> change in workflow is mainly for the developers of the translated software
> rather than the translators.)
>
> {{A side thread to this story: In the F14 time frame (ticket 1455 time
> frame), the translation teams made some valid noise about the problems that
> the version of transifex we were running were causing them. At that time,
> glezos, stickster, some people from l10n and infra analyzed the possibility
> of moving to transifex.net and decided that it was possible but were divided
> about the desirability. We were able to upgrade the FI instance of
> transifex which deferred the question.}}
>
> Sometime between the tests on stg and fudcon some of infra starts worrying
> about how we're going to continue maintaining transifex. beckerde is signing
> up to work on packaging the software and deploying it but we're still running
> several versions behind and we don't have in-house knowledge on how to fix
> issues in the code. Moving to the newest version is caught in the workflow
> changing problem that, since infra isn't involved in using transifex, none of
> us know what is changing or how to approach l10n about changing their
> workflow to accomodate it.
>
> {{Next side thread: mmcgrath leaves as infrastructure leader. This leaves us
> shorthanded as we were already running close to capacity and mmcgrath was
> also a good community leader who was able to entice and induct volunteers.}}
>
> At FUDCon, smooge, skvidal, ricky, CodeBlock meet with igorps and some other
> translators that are present and talk about moving off of Fedora hosting
> transifex if glezos still wants to host us. We talk about a gradual shift at
> that time. Later, infrastructure members talk to glezos on IRC and more with
> each other.
>
> {{Third side note: At FUDCon, infrastructure realizes how deeply
> overcommitted we are. People at "The Next Big Infrastructure Project" were
> excited about a bunch of cool ideas for new services but we realized that to
> do any of them, we needed to either get rid of some of our present
> responsibilities or get new long-term sysadmins to help out.}}
>
> On IRC, post-FUDCon, we talk with glezos and firm up plans a bit more.
> Someone convinces everyone else that moving a little at a time doesn't help
> anyone because there's a lot more confusion if we have two separate places to
> translate at, two procedures to integrate the translations with software,
> etc. Fedora Infrastructure has a meeting where we figure out how we feel
> about migrating transifex service to tx.net. We're in favour. glezos to
> carry the idea for coordination with the l10n team.
>
> At this point things start moving fast. Content is synced to transifex.net
> for a Proof of Concept, meeting with l10n is setup to talk about migrating.
> Decision is made to migrate pre-F15 because the FI-hosted transifex is too
> painful, coordination with developers who will need to pull the translations
> on newer versions of transifex is talked about, duties are assigned for
> migrating, setting up teams, packaging the client-side tools for developers,
> etc. That brings us pretty much to the present.
>
> What I draw from all this is that:
>
> 1) Although communication was present, it didn't involve everyone touched by
> the change. That's pretty hard to achieve in any circumstance but we could
> try to make it better. From infra's point of view, transifex was being
> provided by us to the Fedora l10n team which is not entirely accurate. So
> there needs to be a way to figure out the chain of dependent people.
>
> 2) In some ways, people were just waiting on a decision. Fedora
> Infrastructure was not able to update to the newest transifex because of
> workflow changes. However, once it was decided that Fedora Infrastructure,
> therefore, couldn't upgrade (or fix) transifex at all, it was easy and quick
> for people on l10n to make a decision about changing workflow to get more
> reliable service.
>
> 3) It seems that maintainance is harder to recruit people to work on than a
> new direction. That new direction can even be a continuation of the current
> direction (move to a newer transifex on transifex.net) as long as it's seen
> as a decision needing certain definite actions.
>
>> Jared and Paul said in the meeting log multiple times that we needed to
>> avoid people being surprised by the situation, but unfortunately that
>> wasn't very likely. The timing involved made it a certainty that some
>> people were going to be squeezed, surprised, and upset.
>>
>> I perceive the following items as fait accompli before that meeting
>> happened:
>>
>> * Fedora Infrastructure decided they could no longer provide translation
>> services.
>>
>> * To meet their service obligations, FI put in place a plan to move
>> translation services to Transifex.net.
>>
>> * Fedora Project leadership were essentially in agreemen with that plan.
>>
>> I didn't see the following items as fait accompli before that meeting:
>>
>> * Future of hosting our own translation tool of any kind on
>> fedoraproject.org. Clearly we can revisit this decision, clearly people
>> wanted to.
>>
>> * Ability for resourceful people to step forward and make it possible to
>> either not move for F15 or move back for F16. For example, you seem to have
>> responded to this by seeking new, on-going resource commitments.
>>
>> * Commitment of L10n leadership toward any particular plan. People came in
>> to that meeting with different opinions and agendas, but seemed to come to
>> consensus by the end.
>>
> One note here -- in the meeting skvidal made a statement about what would
> happen if we didn't move to transifex.net which was both harsh and true. But
> it shows that there's another thing that wasn't quite a fait accompli:
>
> * Infrastructure could have continued to host a transifex instance but we
> could not continue to support it (with updates, with fixes for any of the
> numerous open bugs, with the ability to make it more reliable, etc).
> skvidal's projection was that such a strategy, while possible, would
> eventually lead to our instance of transifex preventing work from being done
> at a time when nothing could be done about it making everybody upset.
>
>> Community supported infrastructure doesn't have to be of a lesser service
>> level overall, but things tend to be less formal across the board about
>> change impact on community participants.
>>
>> One lesson to pull from this situation is for *every* service provider
>> (which inclues L10n, Docs, Infrastructure, et al) to have a change
>> management process in place that:
>>
>> 1. Exposes problems (needs for change) early and often. 2. Encourages
>> discussion and work so decisions (why, how) are visible to all affected. 3.
>> Makes sure affected teams are not surprised by developments.
>>
> I'd like to see an infrastructure threat board. Here's an idea of how that
> would work: The threat board would have services that have no dedicated
> person working on them as level red, things that have one or two person
> working on them as level amber, less than five in yellow, and green at five
> or more. A standing policy would be that things in amber or less are in
> danger of being dropped and we need to work on how we're going to gracefully
> drop, outsource, or reassign-drum up help for them (for instance, we can't
> very well drop koji support so if it was in amber, someone would have to come
> across from something else that they were doing to work on that). Perhaps
> once a month, we'd post services that are not green to fedora-devel-announce
> and if we didn't get its levels to rise in X amount of time, we'd be free to
> enact our contingency plans if we chose.
>
> -Toshio
>
--
http://fedoraproject.org/wiki/User:Runab
13 years, 2 months
Re: L10N migration to transifex.net
by Noriko Mizumoto
Stephen John Smoogen さんは書きました:
> 2011/2/24 Karsten Wade <kwade(a)redhat.com>:
>> Caveat here: I wasn't in any meetings, had no foreknowledge of
>> anything, and am not involved in any of these activities. I'm an
>> observer who just read that IRC log and some mailing list threads over
>> the last few days. I'm going to attempt to keep my reply within the
>> confines of these recent activities and my general knowledge of how to
>> do things the open source way.
>>
>> The IRC log in question:
>>
>> http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting...
>>
>> On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
>>> I'm a little confused by the nature of the meetings you're talking about
>>> though. I was only at the docs meeting, and that didn't seem to include
>>> any weighing up of options. For that matter, the L10n meeting didn't
>>> either, based on the logs -- it reads to me more like a fait accompli.
>> I think you are right, and there was clearly confusion about the
>> meaning of the vote. My reading is that everyone understood what they
>> were voting for at the end. It was clear people felt it was rushed,
>> uninformed, and risky to proceed. However, the plans do seem to have
>> seen adjustment in response to L10n concerns.
>>
>> I read the results of the L10n meeting as:
>>
>> Infra: "We really hate to do this, but we have no choice and no time
>> to do anything other than move all L10n services to Tx.net
>> immediately. Sorry about the late notice."
>
Hi Stephen
First of all, I like to express our sincere thanks from our bottom of
hearts to you and all your team members for every effort and time spent
for L10n. Now please allow me to ask further help to understand a little
more the situation where we are standing. It will help to establish an
exit plan in the future.
> Hmm then I was not communicating very clearly:
>
> The issue was that transifex has been an ongoing problem for the
> following reasons:
>
> 1) It is a moving target. Development upstream is fast moving and
> adding new features that translators want.
It seems natural that every software is moving better, adding new
features. However if a feature newly to be added may interfere existing
function, as a user translator, I wish not to have a new feature added.
>
> 2) We are really really behind on upgrades. There have been multiple
> groups who have stepped up, started to do it and then had real life
> hit them with some sort of curve ball. So what started out as 0.7 ->
> 0.8 became 0.7 -> 0.9 and now would have to be 0.7 -> 1.1. We had
> multiple people who for the last 3-4 months have said "We would be
> happy to upgrade, but we aren't really able to do more than that."
I see. So not enough resource can be assigned to such **frequent upgrade
tasks from long term view.
What I am understanding is that the problems we are encountering are
caused by older version, and that the solution is to only upgrade. Is
this correct understanding?
Please let me make the point clear that L10n just wants stable working
version, not necessarily keep upgraded.
What if we upgrade less often?
>
> 3) We could have kept the old transifex going but this seemed to cause
> more problems than it solved. There have been many items where people
> were 'hamstrung' with the current software and wanted us to move to
> something new.
The old transifex above means v0.7 or v0.9.1?
Who is 'people' and what 'items' make these people hamstrung?
At least, there were actually v0.9.1 up on the staging server and
running, which beckerde and lots of people put their time, blood, sweat
and tears [1]. Many of language teams leaders who put themselves in CC
had been watching this ticket and hoping/expecting the v0.9.1 system to
be implemented onto production. What it the cause to make this ticket
abandoned?
Thanks in advance for your help.
noriko
[1]:https://fedorahosted.org/fedora-infrastructure/ticket/2389
>
> 4) In looking at Infrastructures current status I realized that we
> were spending a lot of time on triage and not moving forward with
> projects (and in some cases were moving backwards). We looked at what
> our core missions were and what we could have other people do better.
> And it meant pruning back stuff we were not doing well so we could
> focus on getting things done elsewhere.
>
> Now where we did not hand off things well.
>
> 1) We asked people in L10N and docs about it but did not make sure
> that was communicated clearly with their groups. That meant we ended
> up with thinking we had agreement but didn't.
>
> 2) Web software is hard to keep up with unless people stick to it.
> Volunteer infrastructure scales well for certain items but has had
> problems with long term projects. [This is no different than dealing
> with drupal, plone, most Ruby on Rails etc. If your software is
> updating every 3-6 months it is hard to deploy in a production
> environment unless you have dedicated people to keep up with it.]
>
> 3) As I said in my blog post on this and some other items:
>
> Now usually after a post like this occurs, we get a bunch of
> volunteers who will say "We can take this over." I am asking people
> not to do this, because frankly volunteering under pressure usually
> means leaving when the pressure is gone. We have gone this route
> several times before, and its not something I think is sustainable.
>
> We will look for volunteers who can replant the services, document
> them, build out a staging and production service and train OTHER
> volunteers on them so that any replacement service has a chance of
> lasting.
>
>
>
13 years, 2 months
Re: L10N migration to transifex.net
by Ruediger Landmann
Hey all,
I want to say an enormous thank-you to the logistics folks who have
weighed into this thread -- your replies have been more than generous.
In particular, I want to thank Karsten, abadger, Smooge, and David
Nalley -- plus Ricky earlier in the thread -- for your thoughtful and
helpful insights into the Transifex migration and what led up to it.
It's times like these that I wish we had some formal way of recognizing
awesomeness in Fedora!
I don't really have anything more to add right now, but wanted to
acknowledge each of you guys rather than just let the thread die without
extending my gratitude :)
I also want to reaffirm that even if I'm (evidently!) not happy about
the decision, I'm fully committed to making it work wherever it touches
what I do in Fedora, and I'm behind our leadership 100% here :)
I look forward to revisiting the issue once we've got F15 out the door!
Cheers
Rudi
13 years, 2 months
Re: L10N migration to transifex.net
by Karsten Wade
On Thu, Feb 24, 2011 at 05:17:00PM -0700, Stephen John Smoogen wrote:
>
> The issue was that transifex has been an ongoing problem for the
> following reasons:
<snip important list of reasons/details>
Thanks for providing those details. I meant, and wrote it poorly I'm
sure, that I presume that the situation was much as you described, but
in the end there were people who did not feel/get communicated to. At
that point, Infra and others were saying, "OK, sorry if you didn't
hear about this before, it's been a long-standing problem, and we need
to solve it now before the barn burns down."
So, sorry for characterizing the communication as poor. I think what
I'm seeing could benefit from some change management that all know
about. A lot of times we have to result to a change management list
that goes something like, "OK, ask
$this_list_of_individuals_I_can_think_of, then email
$this_list_of_mailing_lists_I_can_think_of, and write a blog post."
Anyway, I'm sure there is a not-too-much-bureacracy way to do this. I
started this ...
https://fedoraproject.org/wiki/Change_management
... I'm sure there are others who deal with that all the time around
here, maybe there are some existing processes we can adopt,
incorporate, hug, etc.
Thanks,
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
13 years, 2 months
