Bug 731722 - [RFE] Would like to the zanata.xml file to use logical server names
[RFE] Would like to the zanata.xml file to use logical server names
Status: CLOSED WONTFIX
Product: Zanata
Classification: Community
Component: Component-Maven, Component-PythonClient (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Runa Bhattacharjee
Ding-Yi Chen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-18 09:31 EDT by Bryan Kearney
Modified: 2013-03-03 21:21 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-19 21:20:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bryan Kearney 2011-08-18 09:31:46 EDT
We would like to be able to check the zanata.xml file into public projects. However, it references a server name which may be internal. We would like to see a tag in the file which is 

<server>JarJarBinks</server>

which would then link up to the local config file which is:

[servers]
JarJarBinks.url=http://someserver.
JarJarBinks.username=Anakin
JarJarBinks.key=SomeWhineyKid
Comment 1 Sean Flanigan 2011-08-19 01:11:23 EDT
At the moment, zanata.xml has the property that you can look at it and know exactly where the translations are going.  If we replace the server URI in zanata.xml with an alias for a server in someone's zanata.ini, we lose that property.  And if you lose zanata.ini, you lose the connection to Zanata.  Also, it would then be possible for two projects to use the same server alias, but mean two different servers.  I'm not sure if the server name is such a secret that it's worth all the mucking around.

We generally recommend that public projects use a public instance of Zanata, so that the community can help with the translation work more easily.
Comment 2 David Mason 2011-08-19 02:45:45 EDT
If private server names were implemented, it might be worth recommending something like

<server>org.mycompany.thisproject.JarJarBinks</server>

to reduce the potential for name overlaps.
Comment 3 Sean Flanigan 2011-08-19 03:06:26 EDT
Yeah, we need some sort of resource locator, a universal one would be safest!

But seriously, perhaps a URI would help:

<project>my-project</project>
<version>1.0</version>
<uri>http://mycompany.org/thisproject/JarJarBinks</uri>

and zanata.ini would contain:

[servers]
jarjar.uri=http://mycompany.org/thisproject/JarJarBinks
jarjar.url=http://someserver.
jarjar.username=Anakin
jarjar.key=SomeWhineyKid

We won't ever fetch from the URI, it's just a naming signal so that people are more likely to choose unique IDs.  So I think it's more likely to avoid the aliasing problem.

But however we try to avoid aliasing, you still end up with important information about your build deliberately kept out of source control...
Comment 4 Bryan Kearney 2011-08-19 08:02:10 EDT
(In reply to comment #3)
> But however we try to avoid aliasing, you still end up with important
> information about your build deliberately kept out of source control...


Which in some cases may be valid. Currently, we have no public zanata server, so we would like to avoid adding internal server names into public repos. The current strategy is to keep the entire zanata file out of source code control.
Comment 5 Sean Flanigan 2011-09-06 23:06:53 EDT
The affected projects are now on a public server, so I'm assuming we can reduce the severity of this one.

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