Opened 12 years ago

Last modified 9 years ago

#683 new task

Add ASLO to Pootle

Reported by: alsroot Owned by: sayamindu
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: localization Version: Unspecified
Severity: Unspecified Keywords:
Cc: cjl Distribution/OS: Unspecified
Bug Status: Unconfirmed

Change History (7)

comment:1 Changed 12 years ago by sayamindu

Couple of points:

We would probably need to look into ways in which the layout in the source tree can be mapped (via symlinks) to a layout readable by Pootle

The msgids look like:

#. %$1s is a URL
#. %$2s is an email address
#: views/addons/display.thtml:262
#, php-format
msgid "addons_display_paragraph_supportinfoemailurl"
msgstr ""
"Support for this activity is provided by the developer at %1$s or by sending "
"an e-mail to %2$s"

This needs to be handled carefully, as translators (at least the ones from our community) may not be familiar with symbolic msgids and the actual human readable text as the "filler" of msgstr.

I'll look into point 1 asap. Point 2 needs a bit of discussion.

comment:2 follow-up: Changed 12 years ago by cjl

  • Cc cjl added

There was a question on IRC about changing many instances of "add-on" in the UI strings to "activity". This probably needs to happen in the source first (with a new POT then being generated). There is no truly reliable way to communicate this to Pootle users (basically, it would be easier to make the changes in the source UI strings and produce a new POT file rather than consider adding that many translation comments).

comment:3 in reply to: ↑ 2 ; follow-up: Changed 12 years ago by alsroot

Replying to cjl:

There was a question on IRC about changing many instances of "add-on" in the UI strings to "activity". This probably needs to happen in the source first (with a new POT then being generated).

the whole story is: ASLO uses upstream .po, I've just separated sugar related msgids and put them(with proper msgstr) to aslo/po/

so "This probably needs to happen in the source first" means:

  • change msgid, but we have bunch of "addons_display_paragraph_supportinfoemailurl"
  • change translated .po, but i can't imagine how to do it for 35 languages(since we have 35 translations of "addon")
  • replace all translated by upstream strings by en_US strings with "addon" replaced

comment:4 in reply to: ↑ 3 Changed 12 years ago by alsroot

Replying to alsroot:

Replying to cjl:

There was a question on IRC about changing many instances of "add-on" in the UI strings to "activity". This probably needs to happen in the source first (with a new POT then being generated).

the whole story is: ASLO uses upstream .po, I've just separated sugar related msgids and put them(with proper msgstr) to aslo/po/

so "This probably needs to happen in the source first" means:

  • change msgid, but we have bunch of "addons_display_paragraph_supportinfoemailurl"

anyway changing msgid strings means nightmare while merging new upstream commits

comment:5 Changed 10 years ago by alsroot

FIY for now, ASLO is being moved to the new AMO code base, so i18n related stuff might be different and it will affect ongoing(if there is such) work to support ASLO strings on translate.sl.o.

comment:6 follow-up: Changed 9 years ago by cjl

Wha is the current status of this? Is Pootle hosting still required?

comment:7 in reply to: ↑ 6 Changed 9 years ago by alsroot

Replying to cjl:

Wha is the current status of this? Is Pootle hosting still required?

Thats still an open question for me.

The problem is:

1) we have pretty few sugar related string for AMO;
2) the majority of work is "s/Addon/Activity/g'.

The 2) seems for me a wrong way that was taken from the begining. We are separating ourselves from the AMO upstream i18n efforts and do big [useless] work.

I don't see any short running solution except just leave it as-is.

Possible long running solutions:

  • We need to work close w/ upstream to convince them to do big work of unifying i18n strings. I don't know other big AMO installs (maybe I'm wrong, didn't look for recent year news), thus, such work is mostly useless for Mozilla;
  • Looking for other possibilities. AMO does not feet well to Sugar general approach, Mozilla addons are much more simple in comparing w/ regular applications.
Note: See TracTickets for help on using tickets.