Issue 71995 - Set up of the Tatar Native-Lang project
Summary: Set up of the Tatar Native-Lang project
Alias: None
Product: Native-Lang
Classification: NLC
Component: www (show other issues)
Version: OOo 1.0.1
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL: ; http://crh...
Depends on:
Reported: 2006-11-26 18:21 UTC by ooomod
Modified: 2013-02-07 22:38 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

SSH public key. (390 bytes, text/plain)
2008-04-28 09:17 UTC, tatar.iqtelif.i18n
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ooomod 2006-11-26 18:21:48 UTC
Hello Louis,

could you please set up the Tatar Native-Lang project?
There is a requirement that this project should have two domain names (both ISO
standards): "tt" and "crh" This is because of historical and geographical
reasons (see the thread on L10N); please let me know if this is possible.

lead's username: tatar_iqtelif_i18n
JCA signed and sent
Level: 1

Comment 1 lsuarezpotts 2006-12-06 22:33:19 UTC
I can use tt-crh.

is that acceptable?
Comment 2 lsuarezpotts 2006-12-06 23:29:43 UTC
If you have not done so, you must submit a request to have your ssh2 key uploaded. See http://
Comment 3 tatar.iqtelif.i18n 2006-12-17 01:46:45 UTC
We were originally hoping to avoid hyphenation like tt-crh, and to have 2 URLs,
pointing to the same project. That was Charles Schulz's idea.
I would appreciate your feedback on that.

Comment 4 tatar.iqtelif.i18n 2007-05-28 19:14:40 UTC
Could we please re-consider this entry to accommodate the following original
approach (2 URLs resolving to the same entity):

Comment 5 lsuarezpotts 2007-07-16 00:18:01 UTC
I would rather not use two URLs pointing to the same project, as [xx] and 
[yy] ->[zz] In fact, it's actually rather difficult to do, though there are 
hacks around it--and they are indeed hacks.  Each url for a project points to a unique virtual host. 
Thus, points to It doesn't easily point to anything else.  One can 
have the /index.html page include a redirect, that further points people, say to [zz], but 
that's quite clumsy, though people do use them to point to the wiki or outside projects, but visitors will 
first hit the virtual host before being redirected. There are also plusses and minuses with this tactic. For 
instance, how will you specify mail lists or organize them? Issue tracker, too? And so on.  Thus, the 
awkward solution is to have one project with both signifiers in the project name.

Or perhaps I massively misunderstood your desire?  I get the idea of a dual language environment and 
the politics associated with it--I live in Canada--but technologically the solution is to have one 
combined project name--unless (IFF) the languages are quite distinct, in which case then we should 
have two projects, chr and tt, and kill the combined one altogether.  You can then refer each to the 

Let me know what you want done. I'm not averse to expunging the project created and creating the 
new ones, and letting you then sort out how they would communicate with each other; nor am I averse 
even to keeping the combined for combined efforts, though I'd think the wiki would do that job better.

Comment 6 tatar.iqtelif.i18n 2007-07-24 05:56:37 UTC
I was under the impression that it would be easy to point 1 virtual host to
another being a real host, including for email addresses, although i haven't
myself tried that w/ email addresses.
Given the feedback, the following is my inclination:
1. Start off w/ tt project (w/ the understanding that the exact locale i'll be
focusing on initially is tt-RU-iqtelif).
2. Stand by for crh project: w/ the hope that if deemed appropriate and feasible
at the time, the project could indeed be implemented to forward requests to the
kindred/common/shared project (w/ the right set of technologies, this should be
doable for both web requests, and mail requests, but i'm not sure about VCS (i
suspect for VCS, this may entail DNS-level settings, which if used would take
care of web requests, and email requests as well)). If shared project doesn't
work out, or doesn't appear expedient, at the very least, the projects could
share resources w/o having a shared project per se. It's hard to say exactly
what will be optimal and feasible at that time.

I'm also assuming that renaming and tweaking isn't ruled later on, so the above
appears to be sensible for the time being from that point of view as well.

Comment 7 tatar.iqtelif.i18n 2007-07-24 05:57:35 UTC
Re-assigning for proper tracking.
Comment 8 ooomod 2007-07-24 11:18:22 UTC
Sounds very good to me. 
+1 for the Tatar project 'tt'.


Comment 9 tatar.iqtelif.i18n 2008-04-28 08:36:29 UTC
It appears the URL agreed on is still not available:

Please split the current tt-crh into

Also, please find my public ssh key attached in the following update.

Comment 10 tatar.iqtelif.i18n 2008-04-28 09:17:00 UTC
Created attachment 53231 [details]
SSH public key.
Comment 11 ooomod 2008-04-28 13:32:23 UTC

Does this mean that you are ready to provide each tt and crh project pages with
different/localized content? (see louis comments above).

For the ssh key, you need to upload it through a different issue. See here: for more info.

Comment 12 tatar.iqtelif.i18n 2008-04-28 17:30:31 UTC
Yes. The way i see it, putting up those pages would be the easiest part.

If 2 urls pointing to the same location are possible that's fine, if not that's
fine too. Last time we decided to just have 2 separate file systems for the 2 urls.

P.S. I was trying to make a short-cut and not increase the number of issues, but
i guess the process requires it, so i'll enter a new one for the SSH key.