4:05 a.m.
I would like to detail some suggestions I had for Zanata improvements,
engagement for translators and testing.
1. Zanata is missing terminology control. This is a feature already in
Transifex, Pootle and present in most proprietary translation tools out
there.
Terminology control means "glossary", but also aspects of something people
call "controlled language".
In Transifex, each project has an attached terminology, with translation
reviewers being able to update the terminology. My workflow there is a
little clunky, but workable:
I keep at the same time two tabs open, one with Terminology definitions,
where I can add or adjust terms, and a second tab with the translation
interface itself. As I translate, especially a new project, I add new terms
to the list. (An improvement may be to be able to adjust terminology and
translation from the same window)
Setting terminology as translation progresses helps maintain consistency
even if there is just one translator working on it. Unlike the automated
translation memory, terminology provides 'intent' and highlights the
important terms.
As people translate, the terminology words get highlighted, with
suggestions for each one. In Transifex there is inline highlighting
(underlining) and a contextual bubble appears when you hover across the
highlighted term. In Pootle the terminology terms appear to the side in a
separate rectangle, along with their recommended translation and comments.
Other than simply a glossary, terminology control should also highlight
'terminology violations' and have a filter to select only for these strings.
As people add new terms to the terminology, the English variants get all
added to a global list, so if a Japanese reviewer adds a new term, that one
is also available to the French locale (and every other one) -- a good
feature of Transifex. Now, a tool like Pootle only has locale-specific
terms list, so each locale has to figure out their own terminology list. I
prefer the Transifex way.
Something that doesn't exist, but may help: 'hard' and 'soft'
terminology.
Hard terms may be those specific to the application or technical terms with
strict interpretation, while 'soft' ones may be regular language which
needs to be kept consistent, but not critical or with a special meaning for
that project. Hard terms may be global, while soft ones may be
locale-specific.
more nice things to have:
2. Language-specific dashboards for Zanata
for each language, from the Language page (eg.
https://fedora.zanata.org/language/view/fr ):
- latest changed projects, number of strings for each project and who did
them
- a link to a diff-style list with 'before', 'after', 'translator'
for the
last changed strings
3. Diff tools for Zanata: a way to inspect the state of the strings in
'before' and 'after' style picking two arbitrary dates, with github-like
diff coloring for the changes and authors for each string (or substring)
changed.
4. Feature improvement: an option to automatically import strings to a
branch from another branch (for example, from 'development' to F24) for
identical strings. Maybe an option to import identical translated strings
from all other projects.
5. L10n engagement:
- mass-email people who contributed to Fedora from Transifex who have not
yet registered for Zanata (not yet joined a language group)
- mass-email translation contributors, even those not yet on the mailing
lists about the Fedora schedule and deadlines and maybe another mail about
vFAD or translation test day
6. Automatic UI testing
I was wondering if it were possible to set up some kind of automation that
can:
Walk the UI of a given project and take screenshots progressively of the
interface, menus, submenus, windows and contextuals. I understand Gnome
already has a web tool where you can manually inspect the menus, but
something that generates a flat list of screenshots can help people go
through the UI in a faster way. This would be toolkit-specific, but may be
worth investigating if possible.
That is all, thanks!
Jobava
4:16 a.m.
Added Zanata users list as well..
On 9 March 2016 at 15:35, Baadur Jobava <jobaval10n(a)gmail.com> wrote:
I would like to detail some suggestions I had for Zanata
improvements,
engagement for translators and testing.
1. Zanata is missing terminology control. This is a feature already in
Transifex, Pootle and present in most proprietary translation tools out
there.
Terminology control means "glossary", but also aspects of something people
call "controlled language".
In Transifex, each project has an attached terminology, with translation
reviewers being able to update the terminology. My workflow there is a
little clunky, but workable:
I keep at the same time two tabs open, one with Terminology definitions,
where I can add or adjust terms, and a second tab with the translation
interface itself. As I translate, especially a new project, I add new terms
to the list. (An improvement may be to be able to adjust terminology and
translation from the same window)
Setting terminology as translation progresses helps maintain consistency
even if there is just one translator working on it. Unlike the automated
translation memory, terminology provides 'intent' and highlights the
important terms.
As people translate, the terminology words get highlighted, with
suggestions for each one. In Transifex there is inline highlighting
(underlining) and a contextual bubble appears when you hover across the
highlighted term. In Pootle the terminology terms appear to the side in a
separate rectangle, along with their recommended translation and comments.
Other than simply a glossary, terminology control should also highlight
'terminology violations' and have a filter to select only for these strings.
As people add new terms to the terminology, the English variants get all
added to a global list, so if a Japanese reviewer adds a new term, that one
is also available to the French locale (and every other one) -- a good
feature of Transifex. Now, a tool like Pootle only has locale-specific
terms list, so each locale has to figure out their own terminology list. I
prefer the Transifex way.
Something that doesn't exist, but may help: 'hard' and 'soft'
terminology.
Hard terms may be those specific to the application or technical terms with
strict interpretation, while 'soft' ones may be regular language which
needs to be kept consistent, but not critical or with a special meaning for
that project. Hard terms may be global, while soft ones may be
locale-specific.
more nice things to have:
2. Language-specific dashboards for Zanata
for each language, from the Language page (eg.
https://fedora.zanata.org/language/view/fr ):
- latest changed projects, number of strings for each project and who did
them
- a link to a diff-style list with 'before', 'after',
'translator' for the
last changed strings
3. Diff tools for Zanata: a way to inspect the state of the strings in
'before' and 'after' style picking two arbitrary dates, with github-like
diff coloring for the changes and authors for each string (or substring)
changed.
4. Feature improvement: an option to automatically import strings to a
branch from another branch (for example, from 'development' to F24) for
identical strings. Maybe an option to import identical translated strings
from all other projects.
5. L10n engagement:
- mass-email people who contributed to Fedora from Transifex who have not
yet registered for Zanata (not yet joined a language group)
- mass-email translation contributors, even those not yet on the mailing
lists about the Fedora schedule and deadlines and maybe another mail about
vFAD or translation test day
6. Automatic UI testing
I was wondering if it were possible to set up some kind of automation that
can:
Walk the UI of a given project and take screenshots progressively of the
interface, menus, submenus, windows and contextuals. I understand Gnome
already has a web tool where you can manually inspect the menus, but
something that generates a flat list of screenshots can help people go
through the UI in a faster way. This would be toolkit-specific, but may be
worth investigating if possible.
That is all, thanks!
Jobava
_______________________________________________
g11n mailing list
g11n(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/g11n@lists.fedoraproject.org
4:17 a.m.
Another thing I forgot to mention.
Nice to have would also be an option to easily check other language
translations of the source string. For example, for Romanian it's often
useful to inspect the way French, Italian, Spanish, Portuguese translated
it, but it's also less useful to check the Chinese or Japanese translations.
Pootle has a feature where translators can set 'alternate' languages
(individual setting). Mozilla's Pontoon ( https://pontoon.mozilla.org/ )
also lets people check translations made by other locales from the
translation interface.
This could be a cascading series of settings: a global setting (language
families grouped together), a per-locale default setting (decided by locale
leaders), but also adjustable by individual translators. For example:
Romanian, French, Italian, Spanish, Portuguese could be grouped, but French
locale leaders may decide Romanian is not relevant for them, and a French
translator may decide German may be relevant to them. That one French
translator would then get to see translations done by: Italian, Spanish,
Portuguese and German.
Waiting for your feedback.
Jobava
On Wed, Mar 9, 2016 at 12:05 PM, Baadur Jobava <jobaval10n(a)gmail.com> wrote:
I would like to detail some suggestions I had for Zanata
improvements,
engagement for translators and testing.
1. Zanata is missing terminology control. This is a feature already in
Transifex, Pootle and present in most proprietary translation tools out
there.
Terminology control means "glossary", but also aspects of something people
call "controlled language".
In Transifex, each project has an attached terminology, with translation
reviewers being able to update the terminology. My workflow there is a
little clunky, but workable:
I keep at the same time two tabs open, one with Terminology definitions,
where I can add or adjust terms, and a second tab with the translation
interface itself. As I translate, especially a new project, I add new terms
to the list. (An improvement may be to be able to adjust terminology and
translation from the same window)
Setting terminology as translation progresses helps maintain consistency
even if there is just one translator working on it. Unlike the automated
translation memory, terminology provides 'intent' and highlights the
important terms.
As people translate, the terminology words get highlighted, with
suggestions for each one. In Transifex there is inline highlighting
(underlining) and a contextual bubble appears when you hover across the
highlighted term. In Pootle the terminology terms appear to the side in a
separate rectangle, along with their recommended translation and comments.
Other than simply a glossary, terminology control should also highlight
'terminology violations' and have a filter to select only for these strings.
As people add new terms to the terminology, the English variants get all
added to a global list, so if a Japanese reviewer adds a new term, that one
is also available to the French locale (and every other one) -- a good
feature of Transifex. Now, a tool like Pootle only has locale-specific
terms list, so each locale has to figure out their own terminology list. I
prefer the Transifex way.
Something that doesn't exist, but may help: 'hard' and 'soft'
terminology.
Hard terms may be those specific to the application or technical terms with
strict interpretation, while 'soft' ones may be regular language which
needs to be kept consistent, but not critical or with a special meaning for
that project. Hard terms may be global, while soft ones may be
locale-specific.
more nice things to have:
2. Language-specific dashboards for Zanata
for each language, from the Language page (eg.
https://fedora.zanata.org/language/view/fr ):
- latest changed projects, number of strings for each project and who did
them
- a link to a diff-style list with 'before', 'after',
'translator' for the
last changed strings
3. Diff tools for Zanata: a way to inspect the state of the strings in
'before' and 'after' style picking two arbitrary dates, with github-like
diff coloring for the changes and authors for each string (or substring)
changed.
4. Feature improvement: an option to automatically import strings to a
branch from another branch (for example, from 'development' to F24) for
identical strings. Maybe an option to import identical translated strings
from all other projects.
5. L10n engagement:
- mass-email people who contributed to Fedora from Transifex who have not
yet registered for Zanata (not yet joined a language group)
- mass-email translation contributors, even those not yet on the mailing
lists about the Fedora schedule and deadlines and maybe another mail about
vFAD or translation test day
6. Automatic UI testing
I was wondering if it were possible to set up some kind of automation that
can:
Walk the UI of a given project and take screenshots progressively of the
interface, menus, submenus, windows and contextuals. I understand Gnome
already has a web tool where you can manually inspect the menus, but
something that generates a flat list of screenshots can help people go
through the UI in a faster way. This would be toolkit-specific, but may be
worth investigating if possible.
That is all, thanks!
Jobava
6:44 p.m.
----- Original Message -----
Another thing I forgot to mention.
Nice to have would also be an option to easily check other language
translations of the source string. For example, for Romanian it's often
useful to inspect the way French, Italian, Spanish, Portuguese translated
it, but it's also less useful to check the Chinese or Japanese translations.
Pootle has a feature where translators can set 'alternate'
languages
(individual setting). Mozilla's Pontoon ( https://pontoon.mozilla.org/ )
also lets people check translations made by other locales from the
translation interface.
Zanata is capable of showing the alternate language, see the screenshot.
However, you need to get either Keyboard or mouse focus to show that.
This could be a cascading series of settings: a global setting
(language
families grouped together), a per-locale default setting (decided by locale
leaders), but also adjustable by individual translators. For example:
Romanian, French, Italian, Spanish, Portuguese could be grouped, but French
locale leaders may decide Romanian is not relevant for them, and a French
translator may decide German may be relevant to them. That one French
translator would then get to see translations done by: Italian, Spanish,
Portuguese and German.
Waiting for your feedback.
Jobava
I am not sure the centralize approach benefit much. Translators would quite likely to set
their preferred
alternative languages and ignore the pre-defined set. For long messages, showing multiple
languages at the
same time simply took too much space.
But perhaps I am wrong. Would you mind providing a screen shot so we have better idea how
to display them
properly?
--
Ding-Yi Chen
Software Engineer
Globalization Group
DID: +61 7 3514 8239
Email: dchen(a)redhat.com
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com
Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
4:26 a.m.
Hi Jobava,
Is this what you have in mind?
http://docs.zanata.org/en/release/user-guide/translation-reuse/copy-version/
4. Feature improvement: an option to automatically import strings to a
branch from another branch (for example, from 'development'
to F24) for
identical strings. Maybe an option to import identical translated strings
from all other projects.
--
Carlos A. Muñoz
Software Engineering Supervisor
Globalization
Red Hat
3:38 p.m.
Hi,
1. Zanata is missing terminology control. This is a feature already
in
Transifex, Pootle and present in most proprietary translation tools out
there.
While Zanata does have glossary support that apply across all projects, I
do agree we need some sort of granularity and different level of glossary.
(please feel free to file a feedback for us @ zanata.atlassian.net)
Whether its project based, individual based, group based, organisational
based.
With what you described on your workflow, in Zanata, you can actually see
matching glossary term in the editor itself while translating.
And if you prefer to have editing feature, you can open up the glossary
screen in new tab as you had done in your workflow and edit it while
translating.
2. Language-specific dashboards for Zanata
for each language, from the Language page (eg.
https://fedora.zanata.org/language/view/fr ):
- latest changed projects, number of strings for each project and who did
them
- a link to a diff-style list with 'before', 'after',
'translator' for the
last changed strings
Currently all these information is on individual's dashboard which we find
it is more relevant rather than putting in language screen.
I do think we can improve the dashboard by having more information related
to your role (e.g language coordinator, project maintainer) or even just
have more information of your language team.
That would help a user to see all important information in a single screen.
3. Diff tools for Zanata: a way to inspect the state of the strings
in
'before' and 'after' style picking two arbitrary dates, with github-like
diff coloring for the changes and authors for each string (or substring)
changed.
Zanata do have that feature.
http://docs.zanata.org/en/release/user-guide/editor/translation-history/
4. Feature improvement: an option to automatically import strings to a
branch from another branch (for example, from 'development'
to F24) for
identical strings. Maybe an option to import identical translated strings
from all other projects.
Zanata do have that feature.
http://docs.zanata.org/en/release/user-guide/translation-reuse/copy-version/
5. L10n engagement:
- mass-email people who contributed to Fedora from Transifex who have not
yet registered for Zanata (not yet joined a language group)
I think this should be handled by l10n coordinator or the language
coordinator as Zanata has no information on the users before they are
registered.
If you're fedora translator, translator's mailing list should be the
default tool used for any sort of communication.
- mass-email translation contributors, even those not yet on the mailing
lists about the Fedora schedule and deadlines and maybe another mail
about
vFAD or translation test day
Yes, I agree it is nice to have Zanata implement mass emailing to language
contributors. But as workaround for now, mailing list should be sufficient
for these type of communication.
6. Automatic UI testing
I was wondering if it were possible to set up some kind of automation
that
can:
Walk the UI of a given project and take screenshots progressively of the
interface, menus, submenus, windows and contextuals. I understand Gnome
already has a web tool where you can manually inspect the menus, but
something that generates a flat list of screenshots can help people go
through the UI in a faster way. This would be toolkit-specific, but may be
worth investigating if possible.
I believe during QA, there a such infrastructure built and used for test.
But need to check with QA team for confirmation.
---------------------------------------------
Alex Eng
Senior Software Engineer
Globalisation Tools Engineering
DID: +61 3514 8262 <callto:+61+3514+8262>
Mobile: +614 2335 3457 <callto:+614+2335+3457>
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100 <callto:+61+7+3514+8100>
Fax: +61 7 3514 8199 <callto:+61+7+3514+8199>
Website: www.redhat.com
On Wed, Mar 9, 2016 at 8:05 PM, Baadur Jobava <jobaval10n(a)gmail.com> wrote:
> I would like to detail some suggestions I had for Zanata improvements,
> engagement for translators and testing.
>
1. Zanata is missing terminology control. This is a feature already
in
Transifex, Pootle and present in most proprietary translation tools out
there.
>
> Terminology control means "glossary", but also aspects of something people
> call "controlled language".
>
> In Transifex, each project has an attached terminology, with translation
> reviewers being able to update the terminology. My workflow there is a
> little clunky, but workable:
>
> I keep at the same time two tabs open, one with Terminology definitions,
> where I can add or adjust terms, and a second tab with the translation
> interface itself. As I translate, especially a new project, I add new terms
> to the list. (An improvement may be to be able to adjust terminology and
> translation from the same window)
>
> Setting terminology as translation progresses helps maintain consistency
> even if there is just one translator working on it. Unlike the automated
> translation memory, terminology provides 'intent' and highlights the
> important terms.
>
> As people translate, the terminology words get highlighted, with
> suggestions for each one. In Transifex there is inline highlighting
> (underlining) and a contextual bubble appears when you hover across the
> highlighted term. In Pootle the terminology terms appear to the side in a
> separate rectangle, along with their recommended translation and comments.
>
> Other than simply a glossary, terminology control should also highlight
> 'terminology violations' and have a filter to select only for these strings.
>
> As people add new terms to the terminology, the English variants get all
> added to a global list, so if a Japanese reviewer adds a new term, that one
> is also available to the French locale (and every other one) -- a good
> feature of Transifex. Now, a tool like Pootle only has locale-specific
> terms list, so each locale has to figure out their own terminology list. I
> prefer the Transifex way.
>
> Something that doesn't exist, but may help: 'hard' and 'soft'
terminology.
> Hard terms may be those specific to the application or technical terms with
> strict interpretation, while 'soft' ones may be regular language which
> needs to be kept consistent, but not critical or with a special meaning for
> that project. Hard terms may be global, while soft ones may be
> locale-specific.
>
> more nice things to have:
> 2. Language-specific dashboards for Zanata
for each language, from the Language page (eg.
https://fedora.zanata.org/language/view/fr ):
- latest changed projects, number of strings for each project and who did
them
- a link to a diff-style list with 'before', 'after',
'translator' for the
last changed strings
>
3. Diff tools for Zanata: a way to inspect the state of the strings
in
'before' and 'after' style picking two arbitrary dates, with github-like
diff coloring for the changes and authors for each string (or substring)
changed.
>
> 4. Feature improvement: an option to automatically import strings to a
branch from another branch (for example, from 'development'
to F24) for
identical strings. Maybe an option to import identical translated strings
from all other projects.
>
> 5. L10n engagement:
> - mass-email people who contributed to Fedora from Transifex who have not
> yet registered for Zanata (not yet joined a language group)
> - mass-email translation contributors, even those not yet on the mailing
lists about the Fedora schedule and deadlines and maybe another mail
about
vFAD or translation test day
>
> 6. Automatic UI testing
I was wondering if it were possible to set up some kind of automation
that
can:
Walk the UI of a given project and take screenshots progressively of the
interface, menus, submenus, windows and contextuals. I understand Gnome
already has a web tool where you can manually inspect the menus, but
something that generates a flat list of screenshots can help people go
through the UI in a faster way. This would be toolkit-specific, but may be
worth investigating if possible.
>
> That is all, thanks!
>
> Jobava
>
>
> _______________________________________________
> g11n mailing list
> g11n(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/g11n@lists.fedoraproject.org
>
>
2985
days inactive
2986
days old
5 comments
5 participants
participants (5)
-
Alex Eng -
Baadur Jobava -
Carlos Munoz -
Ding Yi Chen -
pravin.d.s＠gmail.com