[Bug 863993] New: The output of "kexec -h" is not localized
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=863993
Bug ID: 863993
QA Contact: aalam(a)redhat.com
Severity: unspecified
Version: unspecified
Priority: unspecified
CC: diegobz(a)gmail.com, fedora(a)couf.be,
piotrdrag(a)gmail.com, trans(a)lists.fedoraproject.org
Assignee: dimitris(a)glezos.com
Summary: The output of "kexec -h" is not localized
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: khashida(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: l10n-requests
Product: Fedora Localization
Description of problem:
The output of "kexec -h" is not translated at all.
Version-Release number of selected component (if applicable):
F18/20120924-test_days-i386.iso
How reproducible:
Everytime "kexec -h" is entered.
Steps to Reproduce:
1.Enter "kexec -h" in the terminal as root.
2.
3.
Actual results:
All the output from the "kexec -h" is in English.
Expected results:
It should be localized.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 657716] New: New translation team
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: New translation team
https://bugzilla.redhat.com/show_bug.cgi?id=657716
Summary: New translation team
Product: Fedora Localization
Version: unspecified
Platform: Unspecified
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: l10n-requests
AssignedTo: dimitris(a)glezos.com
ReportedBy: mohar.darko(a)gmail.com
QAContact: aalam(a)redhat.com
CC: piotrdrag(a)gmail.com, fedora(a)couf.be,
diegobz(a)gmail.com, fedora-trans-list(a)redhat.com
Classification: Fedora
I would like to create a new Fedora Slovenia translation team.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 7 months
[Bug 800846] New: [cs_CZ] There are missing translations in yum
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [cs_CZ] There are missing translations in yum
https://bugzilla.redhat.com/show_bug.cgi?id=800846
Summary: [cs_CZ] There are missing translations in yum
Product: Fedora Localization
Version: unspecified
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: Other language
AssignedTo: dimitris(a)glezos.com
ReportedBy: pschindl(a)redhat.com
QAContact: aalam(a)redhat.com
CC: piotrdrag(a)gmail.com, fedora-trans-list(a)redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
During the installation (or remove or so) I can see this:
...
========================================
Package Arch ... <---
========================================
Shrnutí transakce
========================================
Remove 1 Balíček <---
...
Test transakce v pořádku
Transakce spuštěna
Odstranění : system-config-language-1.3.5-9.fc17.noarch
Verifying : system-config-language-1.3.5-9.fc17.noarch <---
...
Words like Remove, Package and Verifying are still in English, should be in
Czech
Version-Release number of selected component (if applicable):
yum-3.4.3-18.fc17.noarch
How reproducible:
Always
Steps to Reproduce:
1. Install something with yum (for example run 'yum install vim'
Actual results:
Some words aren't translated
Expected results:
Everything should be in Czech
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 7 months
[Bug 768731] New: Transifex file submissions disable f14 and enable f16
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Transifex file submissions disable f14 and enable f16
https://bugzilla.redhat.com/show_bug.cgi?id=768731
Summary: Transifex file submissions disable f14 and enable f16
Product: Fedora Localization
Version: unspecified
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: l10n-requests
AssignedTo: dimitris(a)glezos.com
ReportedBy: guillermo.gomez(a)gmail.com
QAContact: aalam(a)redhat.com
CC: piotrdrag(a)gmail.com, fedora(a)couf.be,
diegobz(a)gmail.com, fedora-trans-list(a)redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
This to request that Transifex file submissions be disabled for the f14 branch
and enabled for the new f16 branch for Software Management Guide book.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 7 months
[Bug 863378] New: F18QA test: im-setting has untranslated lines for most languages.
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=863378
Bug ID: 863378
QA Contact: aalam(a)redhat.com
Severity: unspecified
Version: unspecified
Priority: unspecified
CC: diegobz(a)gmail.com, fedora(a)couf.be,
piotrdrag(a)gmail.com, trans(a)lists.fedoraproject.org
Assignee: dimitris(a)glezos.com
Summary: F18QA test: im-setting has untranslated lines for most
languages.
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: khashida(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: l10n-requests
Product: Fedora Localization
Description of problem:
F18QA has untranslated lines for im-settings-**
Version-Release number of selected component (if applicable):
F18QA version/20120924-test_days-i386.iso
How reproducible:
For each entry of imsettings-check , imsettings-list , imsettings-switch ,
imsettings-info,various outputs will be displayed
Steps to Reproduce:
1.In the terminal, enter each of the above command one by one as root.
2.Observe the output after each entry.
3.
Actual results:
imsettings-switch = translated but one English line.
imsettings-check = No display.
msettings-reload = English.
imsettings-info = English.
imsettings-list = English.
Expected results:
They all should be translated into respective languages.
Additional info:
This problem is common within most languages we support.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years, 1 month
[Bug 866871] New: Fedora18QETest/system-config-kdump has some English entries
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=866871
Bug ID: 866871
QA Contact: aalam(a)redhat.com
Severity: unspecified
Version: unspecified
Priority: unspecified
CC: diegobz(a)gmail.com, fedora(a)couf.be,
piotrdrag(a)gmail.com, trans(a)lists.fedoraproject.org
Assignee: dimitris(a)glezos.com
Summary: Fedora18QETest/system-config-kdump has some English
entries
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: khashida(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: l10n-requests
Product: Fedora Localization
Description of problem:
system-config-kdump gui has some English entries for some languages,
even though upstream files have been translated 100%
Version-Release number of selected component (if applicable):
Fedora18/20120924-test_days-i386.iso
How reproducible:
Every time system-config-kdump is entered.
Steps to Reproduce:
1.In the terminal, enter system-config-kdump as root
2.Observe the gui display
3.There are some English entries.
Actual results:
For Japanese: "Firmware assisted dump" and "Maunual settings" are not
localized.
Expected results:
These entries should be localized for all the languages we support.
Additional info:
Other languages seem to have other entries unlocalized.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years, 7 months
New Websites translation workflow
by Kévin Raymond
Hi there,
I would like to introduce you some changes that I am going to do on the
Websites, that will change a bit the way your are managing the translations.
It is not fixed yet, please give me your thoughts if you think that we need to
improve some parts, remove others or just stick with my proposal.
Don't be afraid, I won't introduce major changes! Oh wait, in fact I will (see
point 5 if you don't want to read this email completly!)
Here are the ideas, with an approximated schedule:
1. We have been pulling all translations twice hourly for years now from
transifex.net (twice because we use staging). That is a slow process, and not
really needed.
Therefore we have started to only pull the translations daily, once (shared
between stg and prod). This is effective only on staging actually, and will move
to production soon. It is transparent on your side, but the fact that we pull
the translations only once a day. You've been warned, now when you translate on
transifex.net, it will only appear on the websites the day after.
This could be moved to daily during string freeze, or a week before the
release. Please tell us if it's needed (I don't think it's really needed but
give your voice).
Of course, if you've made a terrible mistake and something is bad on your
translation, you'll need to wait untill the next day. This is bad. Try to think
if it could happen. But you should really proofread your translations, and I am
sure that you will never get this problem :)
The POs files on the websites repository won't be used at build time. We get the
POs directly from Transifex from inside our infrastructure.
I need your help to check that it is working as it should. Please, translate on
master, and proofread on stg.fedoraproject.org, spins.stg.fedoraproject.org,
start.stg.fedoraproject.org and so on. I would like to be sure that with new
POs it still work. (I can check it but your help is appreciated).
(1.) Expected change by the 13th of Feb
2. Because the POs on the git repo won't be used at build time, they are
probably going to be removed from the repo. Since Transifex keep an history and
the push access are spread between teams, there should not be any really bad
situation (like wrong language overriding). We could keep them here for the
websites team, as we need to test some language build, but I think we will
remove them shortly (as I have seen some commit on Transifex to enable pulling
without being logged in).
(2.) Expected change by the 13th of March
3. Our translation process at release time is not the best. We used to create
alpha, beta and master branches for some websites (mainly fpo and spins.fpo) to
let you translate and review the websites on stg before the release. To do this,
we copyied the translations from the previous branch (master to alpha, alpha to
beta and then beta to master) but doing this:
* The maintainer get the translations credits by Transifex.
* The string history is lost.
* We are all lost because only people on the infra team could know where we are
pulling translations, and on which branch we build the websites.
I already spoke about a new process months ago. Here is a formal introduction:
* We will use only one Transifex resource per website.
* Once we decide to prepare the websites for next release (alpha, beta, finale),
we will freeze the POs on prod (let's take as example alpha, if we are ready
to move to beta) and push the upcoming POT to the current release. You'll then
be able to translate the "new" website on the usual resource. You'll keep your
translation history, the credits etc.
* At the release date (for example for beta), we will just enable again pulling
the POs which would be up to date.
This does not change to much to you as we used to lock the translations during
the freeze, to avoid lost of translations when moved to the next stage (i.e
beta).
Of course, we always try to avoid string freeze break, but again, we depend on
marketing, docs, design, SIGs.. At every release we are making our websites
stronger, which leads to more quality for you.
(3.) Expected change for the F19 Alpha release
4. To let you work on new languages or new websites without loosing the visitors
with a too light translation, we will start pulling only PO files translated at
least with 30% of completion. Please tell me if 30% is too small, 50% could be
fine but I am not sure if we want to make this websites dependant (like 50% of
start.fpo Vs 50% of spins.fedoraproject.org).
With this, a visitor won't be able to select the foo language is the website is
not translated at more than 30% for this specific language.
This is valide for production and staging, we won't be able to separate those
because of the point 1. explained above.
(4.) Expected change by the 13th of Feb
5. There has been a good unknown Transifex feature for months now. The ability
to review translations. I still don't like the way it is implemented: the
maitainer (devs) has to choose for the translator the quality desired. No, it
should come from the translation team. But let move this discussion on an other
thread, later.
Here, on the websites team, we are going to pull reviewed translations only.
That is going to be a *huge* change for you. Therefore, we can probably enable
this feature for specific teams only. I don't know yet how this would be set.
Please every coordinators, tell me if this is something that you don't want for
your team. The downside of this change is the need for your team to mark as
reviewed all your translations.
It could have changed (I did the feature request 3 or 4 months ago)− and don't
ask me which ticket is it, I just can't track them all on their 3 different
trackers) but here is how it works:
* to review a string, you need to do it through the online translation tool
(Lotte) only. You can't authomatize that with the transifex client.
* this is by-string or by-page process. You can't mark as review the whole
resource or project. I let you imagine how to mark as reviewed a project with
several rersources made of thousand of strings... Thanks to Transifex, the
hot feature is a pain to start with. That's mainly why we haven't used that
before, but I got the request to do so and it will add more quality to your
translations. I strongly hope the made something to help us starting.
* only reviewers can review strings. So the language coordinators have to select
some reviewers. A reviewer is a translator that have one more power, the
hability to mark strings as reviewed. You can define them all as reviewers of
course.
(5.) Expected change for the F19 Alpha release. But it really depends if we need
to do this per language, and about your opinion. This is really the major change
for you and we won't move forward on this topic if you don't want this for your
team. That's why I need you to let me know if you don't want this. Yeah, if you
don't reply for your team because you haven't read about this I will assume that
you agreed :) We will choose the best solution for you! (I shall probably send
a reminder..)
Hope you are going to find those point nice, tell me if it's not clear or if you
have better ideas, or if I am missing something.
--
Kévin Raymond
(Shaiton)
10 years, 10 months
Coordinator of Brazilian Portuguese team on Zanata
by Cleiton Felix de Lima
Hello.
As I announced, I'm the new coordinator of Brazilian Portuguese team. I
saw the email from this list saying that some parts of documentation, as
the Installation Guide, are being translated on the Zanata instead of
Transifex. But the coordinator of pt_br team on Zanata was not them same
of the old one on Transifex. I tried to make contact with the
coordinator of the team on Zanata, but he/she don't answered yet. Does
anyone knows how could I act?
10 years, 10 months