ubuntu-translations-coordinators team mailing list archive

[David Planella <david.planella@xxxxxxxxxx>]

** Description changed:

  the online account ui loads the plugins integration from some
  .application files. Those are not translated, not translatable.
  
  What needs to be done, is:
  - rename the .application in .application.in
- - ensuring that upstream have an application.in files with translatable tags (using _)
+ - ensuring that upstream have an application.in files with translatable tags (using _, as in <_description>I want to be translated</_description>). Example [1]
  - add a <translations> tag containing the upstream domain
  - then, at build time:
- 1. running intltool-extract files.applications.in so that it's get merged into a files.applications.in.h
- 2. including the .h file somewhere in the build system (like POTFILES.in for python apps and Makefiles.am for C/vala apps) so that it's merged into the .pot file
- 3. and running intltool-merge --no-translations -x -u foo.applications.in foo.application to create the xml upstream file which is shipped                                                        
- - online-account (the g-c-c plugin) should be patched to load them,  looking at the <translations> tag                                                                        and gettext (package, string)
+ 
+ 1. Running intltool-extract files.applications.in so that it gets merged
+ into a files.applications.in.h file. If you are using intltool already
+ in your build system (and you probably are), this should be happening
+ already and you can skip to step 2.
+ 
+ 2. Including the .in file somewhere in the build system (like
+ po/POTFILES.in for Python apps and Makefiles.am for C/vala apps) so that
+ it's merged into the .pot file. In Python, it's just a matter of adding
+ it as an extra line to the po/POTFILES.in file (example [2]):
+ 
+ [gettext/xml]data/gwibber.application.in
+ 
+ 3. And running intltool-merge --no-translations -x -u foo.applications.in foo.application to create the xml upstream file which is shipped
+ - online-account (the g-c-c plugin) should be patched to load them, looking at the <translations> tag and gettext (package, string)
+ 
+ [1] http://bazaar.launchpad.net/~dpm/+junk/testintl/view/head:/data/gwibber.application.in
+ [2] http://bazaar.launchpad.net/~dpm/+junk/testintl/view/head:/po/POTFILES.in

** Description changed:

- the online account ui loads the plugins integration from some
+ The online accounts UI loads the plugins integration from some
  .application files. Those are not translated, not translatable.
  
  What needs to be done, is:
  - rename the .application in .application.in
  - ensuring that upstream have an application.in files with translatable tags (using _, as in <_description>I want to be translated</_description>). Example [1]
  - add a <translations> tag containing the upstream domain
  - then, at build time:
  
  1. Running intltool-extract files.applications.in so that it gets merged
  into a files.applications.in.h file. If you are using intltool already
  in your build system (and you probably are), this should be happening
  already and you can skip to step 2.
  
  2. Including the .in file somewhere in the build system (like
  po/POTFILES.in for Python apps and Makefiles.am for C/vala apps) so that
  it's merged into the .pot file. In Python, it's just a matter of adding
  it as an extra line to the po/POTFILES.in file (example [2]):
  
  [gettext/xml]data/gwibber.application.in
  
  3. And running intltool-merge --no-translations -x -u foo.applications.in foo.application to create the xml upstream file which is shipped
  - online-account (the g-c-c plugin) should be patched to load them, looking at the <translations> tag and gettext (package, string)
  
  [1] http://bazaar.launchpad.net/~dpm/+junk/testintl/view/head:/data/gwibber.application.in
  [2] http://bazaar.launchpad.net/~dpm/+junk/testintl/view/head:/po/POTFILES.in

** Also affects: ubuntu-translations
   Importance: Undecided
       Status: New

** Changed in: ubuntu-translations
   Importance: Undecided => High

** Changed in: ubuntu-translations
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Translations Coordinators, which is subscribed to Ubuntu Translations.
Matching subscriptions: Ubuntu Translations bug mail
https://bugs.launchpad.net/bugs/1052375

Title:
  The online account g-c-c interface doesn't support i18n

Status in Chat app, and Telepathy user interface:
  New
Status in Gwibber:
  New
Status in Online Accounts: GNOME Control Center:
  New
Status in Shotwell:
  New
Status in Ubuntu Translations:
  Triaged
Status in Google Documents Lens:
  New
Status in Photos Lens:
  New
Status in “empathy” package in Ubuntu:
  Confirmed
Status in “gnome-control-center-signon” package in Ubuntu:
  Confirmed
Status in “gwibber” package in Ubuntu:
  Confirmed
Status in “shotwell” package in Ubuntu:
  Confirmed
Status in “unity-lens-photos” package in Ubuntu:
  Confirmed
Status in “unity-scope-gdocs” package in Ubuntu:
  Confirmed
Status in “empathy” source package in Quantal:
  Confirmed
Status in “gnome-control-center-signon” source package in Quantal:
  Confirmed
Status in “gwibber” source package in Quantal:
  Confirmed
Status in “shotwell” source package in Quantal:
  Confirmed
Status in “unity-lens-photos” source package in Quantal:
  Confirmed
Status in “unity-scope-gdocs” source package in Quantal:
  Confirmed

Bug description:
  The online accounts UI loads the plugins integration from some
  .application files. Those are not translated, not translatable.

  What needs to be done, is:
  - rename the .application in .application.in
  - ensuring that upstream have an application.in files with translatable tags (using _, as in <_description>I want to be translated</_description>). Example [1]
  - add a <translations> tag containing the upstream domain
  - then, at build time:

  1. Running intltool-extract files.applications.in so that it gets
  merged into a files.applications.in.h file. If you are using intltool
  already in your build system (and you probably are), this should be
  happening already and you can skip to step 2.

  2. Including the .in file somewhere in the build system (like
  po/POTFILES.in for Python apps and Makefiles.am for C/vala apps) so
  that it's merged into the .pot file. In Python, it's just a matter of
  adding it as an extra line to the po/POTFILES.in file (example [2]):

  [gettext/xml]data/gwibber.application.in

  3. And running intltool-merge --no-translations -x -u foo.applications.in foo.application to create the xml upstream file which is shipped
  - online-account (the g-c-c plugin) should be patched to load them, looking at the <translations> tag and gettext (package, string)

  [1] http://bazaar.launchpad.net/~dpm/+junk/testintl/view/head:/data/gwibber.application.in
  [2] http://bazaar.launchpad.net/~dpm/+junk/testintl/view/head:/po/POTFILES.in

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/1052375/+subscriptions