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
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.
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.
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...
(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.
The affected projects are now on a public server, so I'm assuming we can reduce the severity of this one.