Bug 961185 - RFE: Provide some way to get exact locales in zanata.xml
Summary: RFE: Provide some way to get exact locales in zanata.xml
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Zanata
Classification: Retired
Component: Component-UI
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Isaac Rooskov
QA Contact: Zanata-QA Mailling List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-09 04:31 UTC by Parag Nemade
Modified: 2015-08-06 05:55 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-12 05:48:53 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1110627 0 unspecified CLOSED RFE: As a command line user I would like to be guided in setting up a project 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1156236 0 medium CLOSED RFE: As a project maintainer, I want to be able to use the latest list of languages defined in the server for a project ... 2021-02-22 00:41:40 UTC

Internal Links: 1110627 1156236

Description Parag Nemade 2013-05-09 04:31:18 UTC
Description of problem:
Provide some client side tool that when run on po directory will generate zanata.xml file locally. This way we don't need to disable some locales which zanata support but my project don't have translations. Otherway I can easily find which new locales need to be added to Zanata.xml

Its really time consuming to find exact zanata.xml for my project.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Sean Flanigan 2013-05-10 01:32:48 UTC
Have you tried getting the Zanata web UI to generate the zanata.xml for you?  We could expose this function through the command line tools if that would help.

If there's a problem with using the generated zanata.xml, could you please explain in more detail?  Perhaps we need to fix something in the client (when pushing and pulling).

Comment 2 Parag Nemade 2013-05-10 03:34:16 UTC
I mean can we have some solution to following problem.

1) I add a new project and branch in Zanata.
2) then, I get chance to disable locales on server side.
3) What is important to project maintainer is to make sure all his existing translations can get place on server side.
4) So, instead I generate zanata.xml on server and download. I want some way by which I get zanata.xml generated locally using all the existing locales in po directory.

This is I need for po format using projects. This can be extended to other translation file formats.

Benefit I see is I don't need to confuse my self and add or remove language codes which are not needed to me in zanata.xml. This will make me more comfortable that all my translations will get uploaded and I don't need to take care of any "401 or 403 client errors" that I used to get with "zanata push --push-type both" command.

In Short, try to prioritize to let end user generate exact zanata.xml and upload it also to server. Let the server then decide which locales be disabled.

Note: This should also take care to write lines   
 <locale map-from="sr">sr-Cyrl</locale>

Comment 3 Ding-Yi Chen 2013-05-10 04:58:06 UTC
Actually this function is included and implemented in zanata-util

zanata_zanata_xml_make <ZanataServerUrl> <ProjectName> <Version>

By default, it downloads the zanata.xml in server and provide the locale map between server locale and existing translation in local directory.

Or adding -m to use locale generated by "locale -a" in local system.

Comment 4 Parag Nemade 2013-05-10 05:06:21 UTC
$ zanata_zanata_xml_make http://translate.zanata.org/ system-config-language f19

[Warn] Failed to download zanata.xml from http://translate.zanata.org/iteration/viem.seam?projectSlug=system-config-language&iterationSlug=f19&actionMethod=iteration%2Fview.xhtml%3AconfigurationAction.getData
[Warn] HTTP::Response=HASH(0x3748e38)->status_line .
[Info] Downloaded from http://translate.zanata.org/iteration/viem.seam?projectSlug=system-config-language&iterationSlug=f19&actionMethod=iteration%2Fview.xhtml%3AconfigurationAction.getData
http://translate.zanata.org/language/list Not Found at /usr/share/perl5/vendor_perl/Zanata/Util/Locale.pm line 376.
[Warn] Failed to parse language list from http://translate.zanata.org/language/list
Done!


And the contents of zanata.xml is only
<config xmlns="http://zanata.org/namespace/config/">
  <url>http://translate.zanata.org/</url>
  <project>system-config-language</project>
  <project-version>f19</project-version>
</config>

Comment 5 Parag Nemade 2013-05-10 05:10:55 UTC
missed to tell I am on F19 and using zanata-util-0.2.9-2.fc19.noarch

Comment 6 Parag Nemade 2013-05-22 03:32:39 UTC
Ping
.
.
.
Ping
.
.
.
Ping

Still waiting for the reply.....

Comment 7 Parag Nemade 2013-05-27 03:25:43 UTC
any one to help to here?

Comment 8 Carlos Munoz 2013-05-28 07:02:21 UTC
I don't think we currently have a way to modify the enabled locales for a project via REST. This would be a first step.

The client would also need to be changed to read the locales locally and then push those locales to the server using the rest endpoint mentioned above. 

If it is a desired feature, we should put it on the backlog and have Isaac prioritize it.

In the meantime, downloading zanata.xml and comparing its locales with the ones in the local directory is the easiest workaround I can think of.

Comment 9 Parag Nemade 2013-05-31 03:57:53 UTC
What I know is please don't ask end user to manually write these lines in their zanata.xml. This is really a big pain.
   <locale map-from="sr@latin">sr-Latn</locale>
    <locale map-from="zh_CN">zh-Hans-CN</locale>
    <locale map-from="es">es-ES</locale>
    <locale map-from="zh_TW">zh-Hant-TW</locale>
    <locale map-from="de">de-DE</locale>
    <locale map-from="en">en-GB</locale>

Do some automation. If I am a dumb user then I will just download zanata.xml from Zanata server and use it and I will not know that few such po files are not getting push at all.

This may make people to run away from Zanata Project.

Comment 10 Parag Nemade 2013-09-10 09:49:33 UTC
I really started hating Zanata now. Fix the zanata.xml issue asap.

Comment 11 Carlos Munoz 2013-09-10 10:56:14 UTC
Parag,

I understand why automating this would make things easier for you. However, there is a workaround for this, and frankly as repetitive as it might be, it is something you only have to do when you start a project and when/if you ever need to add or remove a locale from the list. Even when you are creating a new project version, copying the previous version's zanata.xml should be a fairly (if not fully) complete starting point.

I am cc'ing Isaac to make him aware of this bug, and discuss prioritization.

In the meanwhile, here is how I think this would work, and some problems related to it:

We can add a client-level command to generate the zanata.xml file.
This command would need to pull all available locales for a given project version from the server (and because there is no zanata.xml, the project, version and server would need to be passed via command line). Once this is done, the client would need to scan the local file system looking for localized files (this means using the --includes argument), and try to make a "best guess" on the mappings.

I say a "best guess" because take the following example: if there is a local 'es' file, and the server only contains locales 'es-ES' and 'es-CO' (just an example), then the client would really have no idea which one to map to the local file. This means the user still needs to validate that the zanata.xml file was generated correctly and fixing any possible issues, thus reverting back to a non-automated process.

This is not too different from the current process which is to download zanata.xml and add any necessary locale mappings, and remove unused locales.

Another option like Sean mentioned in comment#1 is to add a way to download zanata.xml. This still leaves you with your current predicament of having to massage the zanata.xml file, but at  least it removes the step of logging into Zanata and downloading the file.

Yet another option that comes to mind is to have a client command that "analyzes" your zanata.xml looking for errors. It could tell a user if it doesn't have all locales available in the server, if it has locales NOT available in the server, and other suspicious things.

Comment 12 Parag Nemade 2013-09-10 15:44:28 UTC
Looks like not a good solution to this problem in near future. Therefore, lowering the priority and severity of this bug.

Comment 13 Parag Nemade 2014-06-04 08:08:13 UTC
Its been more than six months now. Is there any update on this issue? Raising the priority to medium.

Comment 14 Parag Nemade 2015-01-12 05:48:53 UTC
I lost the interest in zanata bugs now.

Comment 15 Carlos Munoz 2015-01-12 06:24:45 UTC
(In reply to Parag from comment #14)
> I lost the interest in zanata bugs now.

Sorry to hear that Parag. Have you seen https://bugzilla.redhat.com/show_bug.cgi?id=1156236?


Note You need to log in before you can comment on or make changes to this bug.