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):
Steps to Reproduce:
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).
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
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.
$ 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
And the contents of zanata.xml is only
missed to tell I am on F19 and using zanata-util-0.2.9-2.fc19.noarch
Still waiting for the reply.....
any one to help to here?
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.
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.
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.
I really started hating Zanata now. Fix the zanata.xml issue asap.
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.
Looks like not a good solution to this problem in near future. Therefore, lowering the priority and severity of this bug.
Its been more than six months now. Is there any update on this issue? Raising the priority to medium.
I lost the interest in zanata bugs now.
(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?