- tor-commits - lists.torproject.org

[torsocks/master] Really fix multiple runs of config.status this time
by hoganrobert＠torproject.org 02 Mar '11

02 Mar '11

commit 339e9597fd77d9e84119f747e9158cb0fc4f4952 Author: Robert Hogan <robert(a)roberthogan.net> Date: Wed Mar 2 20:04:34 2011 +0000 Really fix multiple runs of config.status this time --- configure.in | 12 +++++------- src/Makefile.am | 2 -- test/Makefile.am | 1 + 3 files changed, 6 insertions(+), 9 deletions(-) diff --git a/configure.in b/configure.in index 0291f8f..4bc0e7b 100644 --- a/configure.in +++ b/configure.in @@ -546,8 +546,12 @@ AC_DEFINE_UNQUOTED([SENDMSG_ARGNAMES],[${NAMES}],[Argument names]) # we need to use DYLD_INSERT_LIBRARIES. ############################################################################## +# This variable is used for the LDFLAGS in test/Makefile.am TESTLDFLAGS="$LDFLAGS" +# Version information for libtorsocks +LDFLAGS="$LDFLAGS -version-info 1:0:0" + dnl Linker checks for Mac OSX, which uses DYLD_INSERT_LIBRARIES dnl instead of LD_PRELOAD case "$host_os" in @@ -636,10 +640,4 @@ AC_ENABLE_STATIC AC_CONFIG_FILES([src/usewithtor src/torsocks doc/torsocks.conf.5 doc/torsocks.8 doc/usewithtor.1 doc/torsocks.1]) AC_CONFIG_FILES(Makefile src/Makefile doc/Makefile) -AC_OUTPUT - -dnl Output the Makefile for test/test_torsocks. -dnl Dump any LDFLAGS that were only required for linking libtorsocks, such as -dynamiclib on OSX. -LDFLAGS="$TESTLDFLAGS" -AC_CONFIG_FILES(test/Makefile) -AC_OUTPUT +#AC_OUTPUT diff --git a/src/Makefile.am b/src/Makefile.am index d6da8f3..8d47fb6 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,8 +9,6 @@ INSTALL_SCRIPT = $(install_sh) -c -m 755 # Install main library to $(prefix)/lib/tor (must match torsocks.in) lib_LTLIBRARIES = libtorsocks.la libtorsocks_la_SOURCES = torsocks.c common.c parser.c dead_pool.c darwin_warts.c socks.c -libtorsocks_la_LDFLAGS = -version-info 1:0:0 -#libtorsocks_la_CFLAGS = -nostartfiles DISTCLEANFILES=parser.lo dead_pool.lo common.lo libtorsocks.lo torsocks.lo darwin_warts.lo socks.lo\ config.cache config.log config.h Makefile \ diff --git a/test/Makefile.am b/test/Makefile.am index 84e4859..c04e5ea 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -1,4 +1,5 @@ noinst_PROGRAMS= test_torsocks test_torsocks_SOURCES= test_torsocks.c +test_torsocks_LDFLAGS= $(TESTLDFLAGS) CLEANFILES= test_torsocks

1 0

r24290: {translation} some more text for the translation howto (translation/trunk/documentation)
by Runa Sandvik 02 Mar '11

02 Mar '11

Author: runa Date: 2011-03-02 19:30:13 +0000 (Wed, 02 Mar 2011) New Revision: 24290 Modified: translation/trunk/documentation/howto.txt Log: some more text for the translation howto Modified: translation/trunk/documentation/howto.txt =================================================================== --- translation/trunk/documentation/howto.txt 2011-03-02 17:16:57 UTC (rev 24289) +++ translation/trunk/documentation/howto.txt 2011-03-02 19:30:13 UTC (rev 24290) @@ -288,7 +288,7 @@ Start by checking out the following directory: https://svn.torproject.org/svn/projects/android/trunk/Orbot/. - You can use the following script to convert translated .po files to .xml files:: + You can use the following script to convert translated .po files to .xml files: https://svn.torproject.org/vidalia/vidalia/trunk/src/vidalia/help/content/p… NOTE: You need to have the package 'po4a' installed before running the script. @@ -369,14 +369,17 @@ directory and run 'tx pull'. Remember to commit the changes to SVN. - 2. Converting Translations to + 2. Updating the Translations on the Server Hosting Torcheck - # TODO: document how to convert translations to a useful format. + After pulling new translations from Transifex, someone will have + to put the .po files on the server where Torcheck is running so + that TorCheck.py can find them. 3. Creating/Updating Translation Template Files # TODO: document this as well - + (xgettext cgi-bin/TorCheck.py -dTorCheck -oi18n/TorCheck.pot) + 4. Adding New Translation Resources to Transifex To add new translation resources to Transifex, open up @@ -389,156 +392,59 @@ server, cd to the 'po' directory and run 'tx push' with either '-s' or '-t'. ----------------------------- TorCheck ------------------------------- +The Website: -TorCheck uses our translation portal to accept translations. Users use -the portal to check in their changes. To make use of the translations -that users have committed to the translations/ subversion module, you'll -need to ensure that you have a current checked out copy of TorCheck: + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/website/. + + You will also need to check out the wml files for the website: + https://svn.torproject.org/svn/website/trunk/. - cd check/trunk/i18n/ - check/trunk/i18n$ svn up + 1. Pulling Translations from the Transifex Server -You should see something like the following: + To pull new translations from the server, cd to the 'po' + directory in the translation module and run 'tx pull'. Remember + to commit the changes to SVN. - Fetching external item into 'pootle' - External at revision 15300. + 2. Converting Translations to WML - At revision 15300. + Simply pulling translations from the Transifex server is not + enough. To make use of the translations, you will need to convert + the .po files to .wml files. -Now if you had changes, you'd simply want to move the newly updated .po files -into the current stable directory. Moving the .po files from -'check/trunk/i18n/pootle/' into 'check/trunk/i18n' properly naming the files -for their respective locale. + You can use the 'po2wml.sh' script inside the website module to + convert translated .po files to .wml. Make sure that you check + out the two subversion modules in the same directory, so that you + have (for example) ~/tor/website and ~/tor/translation. + + NOTE: You need to have the package 'po4a' installed before running the script. -Here's an example of how to move all of the current pootle translations into -the svn trunk area of TorCheck: + 3. Creating/Updating Translation Template Files - cd check/trunk/i18n/ - for locale in `ls -1 pootle/|grep -v template`; - do - mv -v pootle/$locale/TorCheck_$locale.po TorCheck_$locale.po; - done + To create a .pot file from a new .wml file, or to update existing + .pot files when one or more website files are updated, run the + 'wml2po.sh' script. Make sure that you check out the two + subversion modules in the same directory, so that you have (for + example) ~/tor/website and ~/tor/translation. -Now check the differences (ensure the output looks reasonable): + 4. Adding New Translation Resources to Transifex - svn diff + To add new translation resources to Transifex, open up + 'po/.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. -Ensure that msgfmt has no errors: + 5. Pushing Files to the Transifex Server - msgfmt -C *.po + To push new/updated source files or translations to the Transifex + server, cd to the 'po' directory and run 'tx push' with either + '-s' or '-t'. -And finally check in the changes: +Tor Manual Pages: - svn commit + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/manpages/ ----------------------------- Torbutton ------------------------------- + 1. Pulling Translations from the Transifex Server -Torbutton uses our translation portal to accept translations. Users use -the portal to check in their changes. - -To make use of the translations that users have committed to the translations/ -subversion module, you'll need to ensure that you have a current checked out -copy of them in your torbutton git checkout: - - cd torbutton.git/trans_tools - torbutton.git/trans_tools$ svn co https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton pootle - -You should see something like the following: - - Checked out revision 21092. - -If you made changes to strings in Torbutton, you need to rebuild the -templates in torbutton.git/trans_tools/pootle/templates. This is done with -the following command from within the torbutton.git checkout directory: - - moz2po -P -i src/chrome/locale/en/ -o trans_tools/pootle/templates/ - -You now have two options: - -Option 1 (The [shitty] Pootle Web UI Way): - -View then commit the changes to the template with: - - cd trans_tools/pootle - svn diff templates - svn commit templates - -Then poke Jake to 'svn up' on the Pootle side. If you do this enough -times, he may give you a button to click to update templates in Pootle, -or maybe even an account on the Pootle server. Persistence is a virtue. - -You then need to go to the Pootle website and click the checkbox next to -every language on: -https://translation.torproject.org/projects/torbutton/admin.html -and then click "Update Languages" at the bottom. - -You then need to go to each language and go to "Editing Options" and click -"Commit" for each one. - -You then need to 'svn up' locally, and follow the procedure above for -rebuilding your .dtd and .properties files. - -Yes, this sucks. :/ - -Option 2 (Use your own msgmerge: YMMV, may change .po flags and formatting): - -Run msgmerge yourself for each language: - - cd trans_tools - for i in `ls -1 pootle` - do - msgmerge -U ./pootle/$i/torbutton.dtd.po ./pootle/templates/torbutton.dtd.pot - msgmerge -U ./pootle/$i/torbutton.properties.po ./pootle/templates/torbutton.properties.pot - done - svn diff pootle - svn commit pootle - -Then poke Jake to 'svn up' on the Pootle side. If you do this enough times, -he may give you a button on Pootle, or maybe even an account on the Pootle -server. Persistence is a virtue. - -You may notice that some .po file flags and string formatting have changed -with this method, depending on your gettext version. It is unclear if this -is a problem. Please update this doc if you hit a landmine and everything -breaks :) - -After this process is done, you then need to regenerate the mozilla -.dtd and .properties files as specified above. - - -Regardless of whether or not you had changes in the torbutton strings, if there -were updated strings in pootle that you checked out from svn you now need to -convert from .po and move the newly updated mozilla files into the current -stable locale directory. First convert them with the 'mkmoz.sh' script and -then move the proper mozilla files from 'torbutton.git/trans_tools/moz/' into -'torbutton.git/src/chrome/locale/' directory while properly naming the files -for their respective locale. - -Here's an example of how to move all of the current pootle translations into -the svn trunk area of Torbutton: - - cd trans_tools - ./mkmoz.sh - for locale in `ls -1 moz/`; - do - mv -v moz/$locale/*.{dtd,properties} ../src/chrome/locale/$locale/ - done - -Now check the differences to your git branch to ensure the output looks -reasonable: - - cd .. - git diff - -And finally check in the changes: - - cd src/chrome/locale - git commit . - ----------------------------- Vidalia ------------------------------- - -Vidalia uses our translation portal to accept translations. Users use the -portal to check in their changes. No conversion or moving is required other -than normal pootle usage. -

1 0

[metrics-utils/master] Remove deprecated bridge descriptor sanitizer.
by karsten＠torproject.org 02 Mar '11

02 Mar '11

commit 96eb27ee126e01168245f6fc0713bfe2981202bb Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Mar 2 18:20:02 2011 +0100 Remove deprecated bridge descriptor sanitizer. There is at least one known issue in this version of the bridge descriptor sanitizer: Bridge IP addresses contained in reject lines are not rewritten as 127.0.0.1. There may be further issues. People should use the bridge descriptor sanitizer that is part of metrics-db instead. --- bridge-desc-sanitizer/ConvertBridgeDescs.java | 461 ------------------------- bridge-desc-sanitizer/HOWTO | 124 ------- bridge-desc-sanitizer/LICENSE | 30 -- bridge-desc-sanitizer/extract-bridges.sh | 8 - 4 files changed, 0 insertions(+), 623 deletions(-) diff --git a/bridge-desc-sanitizer/ConvertBridgeDescs.java b/bridge-desc-sanitizer/ConvertBridgeDescs.java deleted file mode 100644 index a088695..0000000 --- a/bridge-desc-sanitizer/ConvertBridgeDescs.java +++ /dev/null @@ -1,461 +0,0 @@ -import java.io.*; -import java.util.*; -import org.apache.commons.codec.digest.DigestUtils; -import org.apache.commons.codec.binary.*; - -public class ConvertBridgeDescs { - - public static void main(String[] args) throws Exception { - - System.out.println("\n THIS SOFTWARE IS " - + "DEPRECATED !\n\nThere is at least one known issue in this " - + "software: Bridge IP addresses\ncontained in reject lines are " - + "not rewritten as 127.0.0.1. There may be\nfurther issues. " - + "Please use the bridge descriptor sanitizer that is part\nof " - + "metrics-db instead of this software:\n\n" - + " https://gitweb.torproject.org/metrics-db.git\n"); - System.exit(1); - - long started = System.currentTimeMillis(); - - if (args.length < 5) { - System.err.println("Usage: java " - + ConvertBridgeDescs.class.getSimpleName() - + " <input directory> <geoip.txt file> <YYYY> <MM> " - + "<output directory>"); - System.exit(1); - } - File inDir = new File(args[0]); - File geoipFile = new File(args[1]); - String year = args[2]; - String month = args[3]; - int yearInt = Integer.parseInt(year); - int monthInt = Integer.parseInt(month); - File outDir = new File(args[4]); - if (!outDir.exists()) { - outDir.mkdir(); - } - - SortedSet<File> statuses = new TreeSet<File>(); - Set<File> descriptors = new HashSet<File>(); - Set<File> extrainfos = new HashSet<File>(); - - System.out.print("Parsing geoip.txt file... "); - BufferedReader r = new BufferedReader(new FileReader(geoipFile)); - String line0 = null; - SortedMap<Long, String> geoipDatabase = new TreeMap<Long, String>(); - while ((line0 = r.readLine()) != null) { - if (!line0.startsWith("#")) - geoipDatabase.put(Long.parseLong(line0.split(",")[0]), - line0.substring(line0.indexOf(',') + 1)); - } - System.out.println("Found " + geoipDatabase.size() - + " entries (expected 100,000 +- 10,000)."); - - System.out.println("Checking files in " + inDir.getAbsolutePath() - + "..."); - Stack<File> directoriesLeftToParse = new Stack<File>(); - directoriesLeftToParse.push(inDir); - String currentYearAndMonth = "from-tonga-" + year + "-" + month; - String previousYearAndMonth = "from-tonga-" + (monthInt == 1 ? - "" + (yearInt - 1) + "-12" : - year + "-" + (monthInt < 11 ? "0" : "") + (monthInt - 1)); - String nextYearAndMonth = "from-tonga-" + (monthInt == 12 ? - "" + (yearInt + 1) + "-01" : - year + "-" + (monthInt < 9 ? "0" : "") + (monthInt + 1)); - while (!directoriesLeftToParse.isEmpty()) { - File directoryOrFile = directoriesLeftToParse.pop(); - String filename = directoryOrFile.getName(); - boolean addDirectory = false; - if (directoryOrFile.isDirectory()) { - if (/* base directory */ - filename.equals("in") || - /* current month */ - filename.startsWith(currentYearAndMonth) || - /* last days of previous month */ - (filename.startsWith(previousYearAndMonth) - && Integer.parseInt(filename.substring(19, 21)) > 24) || - /* first days of next month */ - (filename.startsWith(nextYearAndMonth) - && Integer.parseInt(filename.substring(19, 21)) < 6)) { - for (File fileInDir: directoryOrFile.listFiles()) { - directoriesLeftToParse.push(fileInDir); - } - } - continue; - } - if (filename.startsWith("cached-extrainfo")) { - extrainfos.add(directoryOrFile); - } else if (filename.equals("bridge-descriptors")) { - descriptors.add(directoryOrFile); - } else if (filename.equals("networkstatus-bridges")) { - statuses.add(directoryOrFile); - } - } - - int days = ((extrainfos.size() / 2 + descriptors.size() - + statuses.size()) + 3 * 24) / (3 * 48); - System.out.println("Found " + extrainfos.size() - + " cached-extrainfo[.new] files, " + descriptors.size() - + " bridge-descriptors files, and " + statuses.size() - + " networkstatus-bridges files, covering approximately " + days - + " days."); - - System.out.print("Parsing extra-info descriptors"); - String[] hex = new String[] { "0", "1", "2", "3", "4", "5", "6", "7", - "8", "9", "a", "b", "c", "d", "e", "f" }; - for (String x : hex) - for (String y : hex) - new File(outDir + File.separator + "extra-infos" + File.separator - + x + File.separator + y).mkdirs(); - Set<File> writtenExtrainfos = new HashSet<File>(); - Map<String, String> extrainfoMapping = new HashMap<String, String>(); - int parsed = 0; - for (File file : extrainfos) { - if (parsed++ > extrainfos.size() / days) { - System.out.print("."); - parsed = 0; - } - BufferedReader br = new BufferedReader(new FileReader(file)); - String line = null; - StringBuilder original = null, scrubbed = null; - boolean skipSignature = false; - while ((line = br.readLine()) != null) { - if (skipSignature && !line.equals("-----END SIGNATURE-----")) { - continue; - } else if (line.startsWith("extra-info ")) { - original = new StringBuilder(line + "\n"); - scrubbed = new StringBuilder("extra-info Unnamed " - + DigestUtils.shaHex(Hex.decodeHex( - line.split(" ")[2].toCharArray())).toUpperCase() + "\n"); - } else if (line.startsWith("published ") - || line.startsWith("write-history ") - || line.startsWith("read-history ") - || line.startsWith("geoip-start-time ") - || line.startsWith("geoip-client-origins ")) { - original.append(line + "\n"); - scrubbed.append(line + "\n"); - } else if (line.startsWith("router-signature")) { - String originalDesc = original.toString() + line + "\n"; - String originalHash = DigestUtils.shaHex(originalDesc); - String scrubbedDesc = scrubbed.toString(); - String scrubbedHash = DigestUtils.shaHex(scrubbedDesc); - if (extrainfoMapping.containsKey(originalHash) && - !extrainfoMapping.get(originalHash).equals(scrubbedHash)) { - System.out.println("We already have an extra-info mapping " - + "from " + originalHash + " to " - + extrainfoMapping.get(originalHash) + ", but we now want " - + "to add a mapping to " + scrubbedHash + ". Exiting"); - System.exit(1); - } - extrainfoMapping.put(originalHash, scrubbedHash); - File out = new File(outDir + File.separator + "extra-infos" - + File.separator + scrubbedHash.charAt(0) + File.separator - + scrubbedHash.charAt(1) + File.separator + scrubbedHash); - if (!out.exists()) { - BufferedWriter bw = new BufferedWriter(new FileWriter(out)); - bw.write(scrubbedDesc); - bw.close(); - writtenExtrainfos.add(out); - } - } else if (line.equals("-----BEGIN SIGNATURE-----")) { - skipSignature = true; - } else if (line.equals("-----END SIGNATURE-----")) { - skipSignature = false; - } else { - System.out.println("Unrecognized line '" + line + "'. Exiting"); - System.exit(1); - } - } - br.close(); - } - System.out.println("\nWrote " + writtenExtrainfos.size() - + " extra-info descriptors."); - - System.out.print("Parsing server descriptors"); - for (String x : hex) - for (String y : hex) - new File(outDir + File.separator + "descriptors" + File.separator - + x + File.separator + y).mkdirs(); - Set<File> writtenDescriptors = new HashSet<File>(); - Map<File, File> referencedExtraInfos = new HashMap<File, File>(); - Map<String, String> descriptorMapping = new HashMap<String, String>(); - int found = 0, notfound = 0; - parsed = 0; - String haveExtraInfo = null; - for (File file : descriptors) { - if (parsed++ > descriptors.size() / days) { - System.out.print("."); - parsed = 0; - } - BufferedReader br = new BufferedReader(new FileReader(file)); - String line = null, country = null; - StringBuilder original = null, scrubbed = null; - boolean skipCrypto = false, contactWritten = false; - while ((line = br.readLine()) != null) { - if (skipCrypto && !line.startsWith("-----END ")) { - original.append(line + "\n"); - continue; - } else if (line.startsWith("router ")) { - original = new StringBuilder(line + "\n"); - country = "zz"; - String[] ipParts = line.split(" ")[2].replace('.', ' ').split(" "); - long ipNum = Long.parseLong(ipParts[0]) * 256L * 256L * 256L - + Long.parseLong(ipParts[1]) * 256L * 256L - + Long.parseLong(ipParts[2]) * 256L - + Long.parseLong(ipParts[3]); - long intervalStart = -1; - if (ipNum >= geoipDatabase.firstKey()) { - intervalStart = geoipDatabase.subMap(0L, ipNum).lastKey(); - String dbContent = geoipDatabase.get(intervalStart); - long intervalEnd = Long.parseLong(dbContent.split(",")[0]); - if (ipNum <= intervalEnd) - country = dbContent.split(",")[1].toLowerCase(); - } - scrubbed = new StringBuilder("router Unnamed 127.0.0.1 " - + line.split(" ")[3] + " " + line.split(" ")[4] + " " - + line.split(" ")[5] + "\n"); - contactWritten = false; - haveExtraInfo = null; - } else if (line.startsWith("opt fingerprint ")) { - original.append(line + "\n"); - scrubbed.append("opt fingerprint"); - String fingerprint = DigestUtils.shaHex(Hex.decodeHex( - line.substring(16).replaceAll(" ", "").toCharArray())). - toUpperCase(); - for (int i = 0; i < fingerprint.length() / 4; i++) - scrubbed.append(" " + fingerprint.substring(4 * i, 4 * (i + 1))); - scrubbed.append("\n"); - } else if (line.startsWith("contact ")) { - original.append(line + "\n"); - scrubbed.append("contact somebody at example dot " + country - + "\n"); - contactWritten = true; - } else if (line.startsWith("router-signature")) { - String originalDesc = original.toString() + line + "\n"; - String originalHash = DigestUtils.shaHex(originalDesc); - String scrubbedDesc = scrubbed.toString(); - String scrubbedHash = DigestUtils.shaHex(scrubbedDesc); - if (descriptorMapping.containsKey(originalHash) && - !descriptorMapping.get(originalHash).equals(scrubbedHash)) { - System.out.println("We already have a descriptor mapping " - + "from " + originalHash + " to " - + descriptorMapping.get(originalHash) + ", but we now " - + "want to add a mapping to " + scrubbedHash - + ". Exiting"); - System.exit(1); - } - descriptorMapping.put(originalHash, scrubbedHash); - if (haveExtraInfo != null) { - File out = new File(outDir + File.separator + "descriptors" - + File.separator + scrubbedHash.charAt(0) + File.separator - + scrubbedHash.charAt(1) + File.separator + scrubbedHash); - if (!out.exists()) { - BufferedWriter bw2 = new BufferedWriter(new FileWriter(out)); - bw2.write(scrubbedDesc); - bw2.close(); - writtenDescriptors.add(out); - String extraInfoHash = haveExtraInfo.toLowerCase(); - File extrainfoFile = new File(outDir + File.separator - + "extra-infos" + File.separator - + extraInfoHash.charAt(0) + File.separator - + extraInfoHash.charAt(1) + File.separator - + extraInfoHash); - if (!extrainfoFile.exists()) { - System.out.println("Extra-info descriptor '" - + extrainfoFile + "' does not exist."); - System.exit(1); - } - referencedExtraInfos.put(out, extrainfoFile); - } - } - } else if (line.startsWith("opt extra-info-digest ")) { - String originalExtraInfo = line.split(" ")[2].toLowerCase(); - if (!extrainfoMapping.containsKey(originalExtraInfo)) { - notfound++; - } else { - found++; - original.append(line + "\n"); - haveExtraInfo = extrainfoMapping.get(originalExtraInfo). - toUpperCase(); - scrubbed.append("opt extra-info-digest " + haveExtraInfo - + "\n"); - } - } else if (line.startsWith("reject ") - || line.startsWith("accept ")) { - if (!contactWritten) { - scrubbed.append("contact nobody at example dot " + country - + "\n"); - contactWritten = true; - } - original.append(line + "\n"); - scrubbed.append(line + "\n"); - } else if (line.startsWith("platform ") - || line.startsWith("opt protocols ") - || line.startsWith("published ") - || line.startsWith("uptime ") - || line.startsWith("bandwidth ") - || line.startsWith("uptime ") - || line.startsWith("opt hibernating ") - || line.equals("opt hidden-service-dir") - || line.equals("opt caches-extra-info")) { - original.append(line + "\n"); - scrubbed.append(line + "\n"); - } else if (line.startsWith("family ")) { - StringBuilder familyLine = new StringBuilder("family"); - for (String s : line.substring(7).split(" ")) { - if (s.startsWith("$")) - familyLine.append(" $" + DigestUtils.shaHex(Hex.decodeHex( - s.substring(1).toCharArray())).toUpperCase()); - else - familyLine.append(" " + s); - } - original.append(line + "\n"); - scrubbed.append(familyLine.toString() + "\n"); - } else if (line.startsWith("@purpose ")) { - continue; - } else if (line.startsWith("-----BEGIN ") - || line.equals("onion-key") || line.equals("signing-key")) { - skipCrypto = true; - original.append(line + "\n"); - } else if (line.startsWith("-----END ")) { - skipCrypto = false; - original.append(line + "\n"); - } else { - System.out.println("Unrecognized line '" + line + "'. Exiting"); - System.exit(1); - } - } - br.close(); - } - System.out.println("\nWrote " + writtenDescriptors.size() - + " bridge descriptors. While parsing, we found that we parsed " - + found + " extra-info identifiers before, but are missing " - + notfound + ". (The number of missing identifiers should be " - + "significantly smaller.)"); - - System.out.print("Parsing network statuses"); - Set<File> referencedDescriptors = new HashSet<File>(); - parsed = notfound = found = 0; - for (File file : statuses) { - if (parsed++ > statuses.size() / days) { - System.out.print("."); - parsed = 0; - } - if (!file.getParent().substring(file.getParent(). - indexOf("from-tonga-")).startsWith(currentYearAndMonth)) { - continue; - } - BufferedReader br = new BufferedReader(new FileReader(file)); - String line = null; - StringBuilder scrubbed = new StringBuilder(); - boolean addSLine = false; - while ((line = br.readLine()) != null) { - if (line.startsWith("r ")) { - String[] parts = line.split(" "); - String bridgeIdentity = parts[2] + "=="; - String hexBridgeIdentity = Hex.encodeHexString( - Base64.decodeBase64(bridgeIdentity)); - String hashedBridgeIdentity2 = Base64.encodeBase64String( - DigestUtils.sha(Base64.decodeBase64(bridgeIdentity))). - replace("=", ""); - String hashedBridgeIdentity = Base64.encodeBase64String( - DigestUtils.sha(Base64.decodeBase64(bridgeIdentity))). - substring(0, 27); - String descIdentifier = parts[3] + "=="; - String hexDescIdentifier = Hex.encodeHexString( - Base64.decodeBase64(descIdentifier)); - if (!descriptorMapping.containsKey(hexDescIdentifier)) { - notfound++; - addSLine = false; - } else { - found++; - String refDesc = descriptorMapping.get(hexDescIdentifier). - toLowerCase(); - File descriptorFile = new File(outDir + File.separator - + "descriptors" + File.separator + refDesc.charAt(0) - + File.separator + refDesc.charAt(1) + File.separator - + refDesc); - if (!descriptorFile.exists()) { - System.out.println("Descriptor file '" - + descriptorFile.getAbsolutePath() + "' does not exist."); - } - String replacementDescIdentifier = Base64.encodeBase64String( - Hex.decodeHex(descriptorMapping.get(hexDescIdentifier). - toCharArray())).substring(0, 27); - scrubbed.append("r Unnamed " + hashedBridgeIdentity - + " " + replacementDescIdentifier + " " + parts[4] + " " - + parts[5] + " 127.0.0.1 " + parts[7] + " " + parts[8] - + "\n"); - addSLine = true; - referencedDescriptors.add(descriptorFile); - } - } else if (line.startsWith("s ")) { - if (addSLine) { - scrubbed.append(line + "\n"); - } - } else { - System.out.println("Unknown line: " + line); - System.exit(1); - } - } - String timeString = file.getParent().substring(file.getParent(). - indexOf("from-tonga-") + 11); - String[] date = timeString.substring(0, 10).split("-"); - String time = timeString.substring(11, 17); - File dir = new File(outDir + File.separator + "statuses" - + File.separator + date[0] + File.separator + date[1] - + File.separator + date[2] + File.separator); - dir.mkdirs(); - File out = new File(dir.getAbsolutePath() + File.separator + date[0] - + date[1] + date[2] + "-" + time + "-" - + "4A0CCD2DDC7995083D73F5D667100C8A5831F16D"); - if (!out.exists()) { - BufferedWriter bw3 = new BufferedWriter(new FileWriter(out)); - bw3.write(scrubbed.toString()); - bw3.close(); - } - } - System.out.println("\nWhile parsing, we found that we parsed " - + found + " bridge descriptors before, but are missing " - + notfound + ". (The number of missing identifiers should be " - + "significantly smaller.)"); - - Set<File> deleteFromReferencedExtraInfos = new HashSet<File>(); - for (File e : referencedExtraInfos.keySet()) { - if (!referencedDescriptors.contains(e)) { - deleteFromReferencedExtraInfos.add(e); - } - } - for (File e : deleteFromReferencedExtraInfos) { - referencedExtraInfos.remove(e); - } - SortedSet<File> deleteDescriptors = new TreeSet<File>(); - for (File e : writtenDescriptors) { - if (!referencedDescriptors.contains(e)) { - deleteDescriptors.add(e); - } - } - SortedSet<File> deleteExtraInfos = new TreeSet<File>(); - for (File e : writtenExtrainfos) { - if (!referencedExtraInfos.values().contains(e)) { - deleteExtraInfos.add(e); - } - } - System.out.println("Deleting " + deleteDescriptors.size() - + " unreferenced bridge descriptors and " - + deleteExtraInfos.size() + " extra-info descriptors (keeping " - + (writtenDescriptors.size() - deleteDescriptors.size()) - + " bridge descriptors and " + (writtenExtrainfos.size() - - deleteExtraInfos.size()) + " extra-info descriptors)."); - for (File e : deleteDescriptors) - e.delete(); - for (File e : deleteExtraInfos) - e.delete(); - - long finished = System.currentTimeMillis(); - System.out.println("Processing took " + ((finished - started) / 1000) - + " seconds."); - } -} - diff --git a/bridge-desc-sanitizer/HOWTO b/bridge-desc-sanitizer/HOWTO deleted file mode 100644 index 418dc5f..0000000 --- a/bridge-desc-sanitizer/HOWTO +++ /dev/null @@ -1,124 +0,0 @@ -Bridge descriptor sanitizer - ---------------------------------------------------------------------------- - - THIS SOFTWARE IS DEPRECATED ! - -There is at least one known issue in this software: Bridge IP addresses -contained in reject lines are not rewritten as 127.0.0.1. There may be -further issues. Please use the bridge descriptor sanitizer that is part -of metrics-db instead of this software: - - https://gitweb.torproject.org/metrics-db.git - ---------------------------------------------------------------------------- - -Introduction: - -The bridge authority Tonga keeps a list of bridges in order to serve bridge -addresses and descriptors to its clients. Every half hour, Tonga copies a -snapshot of the known bridge descriptors to moria where these descriptors -are archived for later statistical analysis. As a guiding principle, the -Tor project makes all data that it uses for statistical analysis available -to the interested public, in order to maximize transparency towards the -community. However, the bridge descriptors contain the IP addresses and -other contact information of bridges that must not be made public, or the -purpose of bridges as non-public entry points into the Tor network would be -obsolete. This script takes the half-hourly snapshots as input, removes all -possibly sensitive information from the descriptors, and puts out the -sanitized bridge descriptors that are safe to be published. - ---------------------------------------------------------------------------- - -Processing steps: - -The following steps are taken to remove all potentially sensitive -information from the bridge descriptors while keeping them useful for -statistical analysis. - -1. Replace the bridge identity with its SHA1 value - - Clients can request a bridge's current descriptor by sending its - identity string to the bridge authority. This is a feature to make - bridges on dynamic IP addresses useful. Therefore, the original - identities (and anything that could be used to derive them) need to be - removed from the descriptors. The bridge identity is replaced with its - SHA1 hash value. The idea is to have a consistent replacement that - remains stable over months or even years (without keeping a secret for a - keyed hash function). - -2. Remove all cryptographic keys and signatures - - It would be straightforward to learn about the bridge identity from the - bridge's public key. Replacing keys by newly generated ones seemed to be - unnecessary (and would involve keeping a state over months/years), so - that all cryptographic objects have simply been removed. - -3. Replace IP address with 127.0.0.1 - - Of course, the IP address needs to be removed, too. However, the IP - address is resolved to a country code first and the result written to - the contact line as "somebody at example dot de" for Germany, etc. The - ports are kept unchanged though. - -4. Replace contact information - - If there is contact information in a descriptor, the contact line is - changed to "somebody at ...". If there is none, a contact line is added - saying "nobody at ..." in order to put in the country code. - -5. Replace nickname with Unnamed - - The bridge nicknames might give hints on the location of the bridge if - chosen without care; e.g. a bridge nickname might be very similar to the - operators' relay nicknames which might be located on adjacent IP - addresses. All bridge nicknames are therefore replaced with the string - Unnamed. - -Note that these processing steps only prevent people from learning about -new bridge locations. People who already know a bridge identity or location -can easily learn more about this bridge from the sanitized descriptors. -This is useful for statistical analysis, e.g. to filter out bridges that -have been running as relays before. - ---------------------------------------------------------------------------- - -Quick Start: - -The following steps are necessary to process the half-hourly snapshots as -collected by moria: - -- Install Java 5 or higher. - -- Download Apache Commons Codec 1.4 or higher for Base 64 and hex encoding - from http://commons.apache.org/codec/ and place the .jar (in the - following assumed to be commons-codec-1.4.jar) in the same directory as - this HOWTO file. - -- Copy the half-hourly snapshots named from-tonga-YYYY-MM-DDThhmmssZ.tar.gz - in a directory called data/ in the same directory as this HOWTO file. - -- Run ./extract-bridges.sh to extract the half-hourly snapshots in data/ - to separate directories in the newly created subdirectory in/ . - -- Copy the geoip.txt from the Tor sources (from /src/config/) to the same - directory as this HOWTO file. - -- Compile the Java class using - - $ javac -cp commons-codec-1.4.jar ConvertBridgeDescs.java - -- Run the script, providing it with the parameters it needs: - - java -cp .:commons-codec-1.4.jar ConvertBridgeDescs - <input directory> <geoip.txt file> - <YYYY> <MM> <output directory> - - Note that YYYY and MM specify the month that shall be processed. The other - descriptors in the input directory are ignored. - - A sample invocation might be: - - $ java -cp .:commons-codec-1.4.jar ConvertBridgeDescs in/ geoip.txt - 2008 10 out/ - diff --git a/bridge-desc-sanitizer/LICENSE b/bridge-desc-sanitizer/LICENSE deleted file mode 100644 index ad177ea..0000000 --- a/bridge-desc-sanitizer/LICENSE +++ /dev/null @@ -1,30 +0,0 @@ -Copyright 2009-2010 The Tor Project - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are -met: - -* Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - -* Redistributions in binary form must reproduce the above - copyright notice, this list of conditions and the following disclaimer - in the documentation and/or other materials provided with the - distribution. - -* Neither the names of the copyright owners nor the names of its - contributors may be used to endorse or promote products derived from - this software without specific prior written permission. - -THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - diff --git a/bridge-desc-sanitizer/extract-bridges.sh b/bridge-desc-sanitizer/extract-bridges.sh deleted file mode 100755 index 5f412c3..0000000 --- a/bridge-desc-sanitizer/extract-bridges.sh +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/bash -mkdir "in/" -for i in `ls data/ | cut -c 1-29` -do -mkdir "in/"$i -tar -C "in/"$i -xf "data/"$i".tar.gz" -done -

1 0

[torspec/master] tweak ipv6 plan more
by nickm＠torproject.org 02 Mar '11

02 Mar '11

commit 2fa1377bdc200cecd0c36ba4104f3da156ba1ea8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 2 12:21:56 2011 -0500 tweak ipv6 plan more --- proposals/ideas/xxx-ipv6-plan.txt | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt index 12bd4d4..73a21f1 100644 --- a/proposals/ideas/xxx-ipv6-plan.txt +++ b/proposals/ideas/xxx-ipv6-plan.txt @@ -18,17 +18,14 @@ Motivation: What needs to change: - Tor uses the Internet in many ways. There are four main ways that + Tor uses the Internet in many ways. There are three main ways that will need to change for IPv6 support, from most urgent to least urgent. - 0. An unknown laundry list of issues that will supersede all other - listed issues in this list. - 1. Tor must allow connections from IPv6-only clients. (Currently, routers and bridges do not listen on IPv6 addresses, and can't - advertise that they support IPv6 addresses, so clients can't learn that - they do.) + advertise that they support IPv6 addresses, so clients can't + learn that they do.) 2. Tor must transport IPv6 traffic and IPv6-related DNS traffic. (Currently, Tor only allows BEGIN cells to ask for connections @@ -38,11 +35,14 @@ What needs to change: 3. Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we - do, these clients will be unable to connect to Tor at all. Next most - important is to support IPv6 DNS related dependencies and exiting to IPv6 - services. Finally, allowing Tor nodes to support a dual stack of both IPv4 - and IPv6 for interconnection seems like a reasonable step towards a fully - hybrid v4/v6 Tor network. + do, these clients will be unable to connect to Tor at all. Next + most important is to support IPv6 DNS related dependencies and + exiting to IPv6 services. Finally, allowing Tor nodes to support a + dual stack of both IPv4 and IPv6 for interconnection seems like a + reasonable step towards a fully hybrid v4/v6 Tor network. + + Of course, more issues may be discovered as we develop solutions for these + issues, some of which may need to take priority. Designs that we will need to do:

1 0

[torspec/master] ipv6-plan patch from ioerror
by nickm＠torproject.org 02 Mar '11

02 Mar '11

commit 2cb38a6ef43fd3b5de7508622a815d8810275e0b Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 2 11:29:41 2011 -0500 ipv6-plan patch from ioerror --- proposals/ideas/xxx-ipv6-plan.txt | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt index e9ffb10..12bd4d4 100644 --- a/proposals/ideas/xxx-ipv6-plan.txt +++ b/proposals/ideas/xxx-ipv6-plan.txt @@ -18,13 +18,16 @@ Motivation: What needs to change: - Tor uses the Internet in many ways. There four main ways that + Tor uses the Internet in many ways. There are four main ways that will need to change for IPv6 support, from most urgent to least urgent. + 0. An unknown laundry list of issues that will supersede all other + listed issues in this list. + 1. Tor must allow connections from IPv6-only clients. (Currently, - routers do not listen on IPv6 addresses, and can't advertise - that they support IPv6 addresses, so clients can't learn that + routers and bridges do not listen on IPv6 addresses, and can't + advertise that they support IPv6 addresses, so clients can't learn that they do.) 2. Tor must transport IPv6 traffic and IPv6-related DNS traffic. @@ -35,8 +38,11 @@ What needs to change: 3. Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we - do, these unable to connect to Tor at all. Next most - important is to allow IPv6 XXXX + do, these clients will be unable to connect to Tor at all. Next most + important is to support IPv6 DNS related dependencies and exiting to IPv6 + services. Finally, allowing Tor nodes to support a dual stack of both IPv4 + and IPv6 for interconnection seems like a reasonable step towards a fully + hybrid v4/v6 Tor network. Designs that we will need to do: @@ -51,13 +57,16 @@ Designs that we will need to do: for places that might assume that IPs are a scarce resource. For example, clients assume that any two routers occupying an IPv4 /16 network are "too close" topologically to be used in the same - circuit, and the bridgedb https distributor assumes that hopping + circuit, and the bridgedb HTTPS distributor assumes that hopping from one /24 to another takes a little effort for most clients. The directory authorities assume that blacklisting an IP is an okay response to a bad router at that address. These and other places will needed instead more appropriate notions of "closeness" and "similarity". + We'll want to consider geographic and political boundaries rather than + purely mathematical notions such as the size of network blocks. + We'll need a way to advertise IPv6 bridges, and to use them. For transporting IPv6-only traffic, we have another accepted design

1 0

r24289: {website} updated translations for the website as wml files (in website/trunk: about/ru docs/en download/en projects/en)
by Runa Sandvik 02 Mar '11

02 Mar '11

Author: runa Date: 2011-03-02 17:16:57 +0000 (Wed, 02 Mar 2011) New Revision: 24289 Modified: website/trunk/about/ru/overview.wml website/trunk/docs/en/faq.wml website/trunk/download/en/download-easy.wml website/trunk/projects/en/torbrowser.wml website/trunk/projects/en/vidalia.wml Log: updated translations for the website as wml files Modified: website/trunk/about/ru/overview.wml =================================================================== --- website/trunk/about/ru/overview.wml 2011-03-02 16:43:14 UTC (rev 24288) +++ website/trunk/about/ru/overview.wml 2011-03-02 17:16:57 UTC (rev 24289) @@ -4,7 +4,7 @@ ## translation metadata -# Revision: $Revision: 23689 $ +# Revision: $Revision: 24254 $ # Translation-Priority: 2-medium #include "head.wmi" TITLE="Tor Project: Overview" CHARSET="UTF-8" <div id="content" class="clearfix"> @@ -154,8 +154,6 @@ определённо сказать, откуда данные пришли и куда они направляются. - <img alt="Первый шаг цепи Tor" src="$(IMGROOT)/htw1.png"> - Чтобы создать приватный путь с помощью Tor, программа пользователя или клиент последовательно строит цепочки зашифрованных соединений с серверами Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2011-03-02 16:43:14 UTC (rev 24288) +++ website/trunk/docs/en/faq.wml 2011-03-02 17:16:57 UTC (rev 24289) @@ -1577,6 +1577,7 @@ problems are: +<ol> <li>IP packets reveal OS characteristics. We would still need to do IP-level packet normalization, to stop things like TCP fingerprinting attacks. Given the diversity and complexity of TCP stacks, along with <a Modified: website/trunk/download/en/download-easy.wml =================================================================== --- website/trunk/download/en/download-easy.wml 2011-03-02 16:43:14 UTC (rev 24288) +++ website/trunk/download/en/download-easy.wml 2011-03-02 17:16:57 UTC (rev 24289) @@ -19,7 +19,7 @@ <td>The Tor Browser Bundle contains everything you need to safely browse the Internet. This package requires no installation. Just extract it and run. <a href="<page projects/torbrowser>">Learn more -&amp other languages »</a></td> +& other languages »</a></td> </tr> <tr class="gray"> <td> @@ -28,6 +28,7 @@ (<a href="../dist/torbrowser/tor-browser-<version-torbrowserbundle>_en-US.exe.asc">sig</a>) </td> +</tr> <tr> <td> # Translators: please point to the version of TBB in your language, if there is one. Modified: website/trunk/projects/en/torbrowser.wml =================================================================== --- website/trunk/projects/en/torbrowser.wml 2011-03-02 16:43:14 UTC (rev 24288) +++ website/trunk/projects/en/torbrowser.wml 2011-03-02 17:16:57 UTC (rev 24289) @@ -240,7 +240,8 @@ Click Extract (3) to begin extraction. This may take a few minutes to complete. - <img src="$(IMGROOT)/tbb-screenshot1.png" alt="Screenshot of extraction process"> + <img src="$(IMGROOT)/tbb-screenshot1.png" alt="Screenshot of +extraction process" /> <a id="Usage"></a> <h3><a class="anchor" href="#Usage">Usage</a></h3> @@ -252,7 +253,8 @@ The Vidalia window will shortly appear. - <img src="$(IMGROOT)/tbb-screenshot2.png" alt="Screenshot of bundle startup"> + <img src="$(IMGROOT)/tbb-screenshot2.png" alt="Screenshot of +bundle startup" /> Once Tor is ready, Firefox will automatically be opened. Only web pages visited through the included Firefox browser will be sent via Tor. Other web @@ -264,15 +266,18 @@ If you installed the Tor IM Browser Bundle, the Pidgin instant messaging client will also be automatically opened. Once you are finished browsing, close any open Firefox windows by clicking - on the <img src="$(IMGROOT)/tbb-close-button.png" alt="Close button (×)"> (6). + on the <img src="$(IMGROOT)/tbb-close-button.png" alt="Close button +(×)" /> (6). For privacy reasons, the list of webpages you visited and any cookies will be deleted. - <img src="$(IMGROOT)/tbb-screenshot3a.png" alt="Screenshot of Firefox"> + <img src="$(IMGROOT)/tbb-screenshot3a.png" alt="Screenshot of +Firefox" /> With the Tor Browser Bundle, Vidalia and Tor will automatically close. With the Tor IM Browser Bundle you need to also close Pidgin by right-clicking on the Pidgin icon (7), and choosing Quit (8). - <img src="$(IMGROOT)/tbb-screenshot3b.png" alt="Screenshot of Pidgin"> + <img src="$(IMGROOT)/tbb-screenshot3b.png" alt="Screenshot of +Pidgin" /> To use the Tor Browser Bundle or Tor IM Browser Bundle again, repeat the steps in <a href="#Usage">"Usage"</a>. Modified: website/trunk/projects/en/vidalia.wml =================================================================== --- website/trunk/projects/en/vidalia.wml 2011-03-02 16:43:14 UTC (rev 24288) +++ website/trunk/projects/en/vidalia.wml 2011-03-02 17:16:57 UTC (rev 24289) @@ -17,7 +17,8 @@  <div class="sidebar-left"> - <img src="$(IMGROOT)/Screenshot-Vidalia-Control-Panel.png" width="261" height="255" alt="Vidalia Control Panel Screenshot"> + <img src="$(IMGROOT)/Screenshot-Vidalia-Control-Panel.png" +width="261" height="255" alt="Vidalia Control Panel Screenshot"/> </div>  @@ -114,6 +115,7 @@ channel, or #tor-dev. + If you have any doubts about any of the points in here, you can email <a href="<page about/contact>">contact us</a> about it.

1 0

r24288: {translation} more text, some nitpicking, still work in progress (translation/trunk/documentation)
by Runa Sandvik 02 Mar '11

02 Mar '11

Author: runa Date: 2011-03-02 16:43:14 +0000 (Wed, 02 Mar 2011) New Revision: 24288 Modified: translation/trunk/documentation/howto.txt Log: more text, some nitpicking, still work in progress Modified: translation/trunk/documentation/howto.txt =================================================================== --- translation/trunk/documentation/howto.txt 2011-03-02 15:46:57 UTC (rev 24287) +++ translation/trunk/documentation/howto.txt 2011-03-02 16:43:14 UTC (rev 24288) @@ -1,16 +1,16 @@ # This file documents the translation process for all projects # currently available in the Tor translation portal: # -# *. BridgeDB -# *. GetTor -# *. Vidalia Help Files -# *. Vidalia Installer -# *. Vidalia -# *. Orbot -# *. Torbutton-alpha -# *. Torbutton -# *. Torcheck -# *. The Website +# * BridgeDB +# * GetTor +# * Vidalia Help Files +# * Vidalia Installer +# * Vidalia +# * Orbot +# * Torbutton-alpha +# * Torbutton +# * Torcheck +# * The Website # * Tor Manual Pages # # ( More translation information for Tor related apps and documentation @@ -235,8 +235,8 @@ 5. Pushing Files to the Transifex Server - To push new/updated source files or translations to the Transifex, - simply run 'tx push' with either '-s' or '-t'. + To push new/updated source files or translations to the Transifex + server, simply run 'tx push' with either '-s' or '-t'. Vidalia: @@ -266,7 +266,7 @@ 5. Pushing Files to the Transifex Server To push new/updated source files or translations to the - Transifex, simply run 'tx push' with either '-s' or '-t'. + Transifex server, simply run 'tx push' with either '-s' or '-t'. Orbot: @@ -314,7 +314,7 @@ 5. Pushing Files to the Transifex Server To push new/updated source files or translations to the - Transifex, simply run 'tx push' with either '-s' or '-t'. + Transifex server, simply run 'tx push' with either '-s' or '-t'. Torbutton and Torbutton-alpha: @@ -324,15 +324,71 @@ and here: https://svn.torproject.org/svn/translation/trunk/projects/torbutton-alpha/. + You will also need: https://gitweb.torproject.org/torbutton.git/. + 1. Pulling Translations from the Transifex Server - To pull new translations from the server, run 'tx pull'. Remember - to commit the changes to SVN. + To pull new translations from the server, cd to the 'po' + directory and run 'tx pull'. Remember to commit the changes to + SVN. + 2. Converting Translations to Mozilla Files + # TODO: document how to convert translations to mozilla files. + + 3. Creating/Updating Translation Template Files + If you made changes to strings in Torbutton, you need to rebuild + the templates in the 'po/templates' directory. This is done with + the following command from within the torbutton.git checkout + directory: + $ moz2po -P -i src/chrome/locale/en/ -o /path/to/po/templates + 4. Adding New Translation Resources to Transifex + + To add new translation resources to Transifex, open up + 'po/.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. + + 5. Pushing Files to the Transifex Server + + To push new/updated source files or translations to the Transifex + server, cd to the 'po' directory and run 'tx push' with either + '-s' or '-t'. + +Torcheck: + + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/torcheck/. + + 1. Pulling Translations from the Transifex Server + + To pull new translations from the server, cd to the 'po' + directory and run 'tx pull'. Remember to commit the changes to + SVN. + + 2. Converting Translations to + + # TODO: document how to convert translations to a useful format. + + 3. Creating/Updating Translation Template Files + + # TODO: document this as well + + 4. Adding New Translation Resources to Transifex + + To add new translation resources to Transifex, open up + 'po/.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. + + 5. Pushing Files to the Transifex Server + + To push new/updated source files or translations to the Transifex + server, cd to the 'po' directory and run 'tx push' with either + '-s' or '-t'. + ---------------------------- TorCheck ------------------------------- TorCheck uses our translation portal to accept translations. Users use

1 0

[torspec/master] Sebastian confirms that 178 should be "Open"
by nickm＠torproject.org 02 Mar '11

02 Mar '11

commit 304314dc6d0ec77887125ed7e34caf3d3ca49c09 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 2 11:25:44 2011 -0500 Sebastian confirms that 178 should be "Open" --- proposals/000-index.txt | 4 ++-- proposals/178-param-voting.txt | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 91c2f27..b642703 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -98,7 +98,7 @@ Proposals by number: 175 Automatically promoting Tor clients to nodes [DRAFT] 176 Proposed version-3 link handshake for Tor [OPEN] 177 Abstaining from votes on individual flags [OPEN] -178 Require majority of authorities to vote for consensus parameters [DRAFT] +178 Require majority of authorities to vote for consensus parameters [OPEN] Proposals by status: @@ -112,7 +112,6 @@ Proposals by status: 149 Using data from NETINFO cells [for 0.2.1.x] 170 Configuration options regarding circuit building 175 Automatically promoting Tor clients to nodes - 178 Require majority of authorities to vote for consensus parameters NEEDS-REVISION: 131 Help users to verify they are using Tor OPEN: @@ -130,6 +129,7 @@ Proposals by status: 171 Separate streams across circuits by connection metadata 176 Proposed version-3 link handshake for Tor [for 0.2.3] 177 Abstaining from votes on individual flags + 178 Require majority of authorities to vote for consensus parameters ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.1.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.1.x] diff --git a/proposals/178-param-voting.txt b/proposals/178-param-voting.txt index ff3d055..b5664b5 100644 --- a/proposals/178-param-voting.txt +++ b/proposals/178-param-voting.txt @@ -2,7 +2,7 @@ Filename: 178-param-voting.txt Title: Require majority of authorities to vote for consensus parameters Author: Sebastian Hahn Created: 16-Feb-2011 -Status: Draft +Status: Open Overview:

1 0

[torspec/master] Close proposal 166 and make xxx-geoip-survey-plan obsolete
by nickm＠torproject.org 02 Mar '11

02 Mar '11

commit 6501e1e80a6eb44aa1ff089ced2870b6728865a8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 2 11:20:33 2011 -0500 Close proposal 166 and make xxx-geoip-survey-plan obsolete Karsten confirms that 166 is implemented, and xxx-geoip-survey-plan is superseded by this tech report: https://metrics.torproject.org/papers/countingusers-2010-11-30.pdf --- proposals/000-index.txt | 4 +- proposals/166-statistics-extra-info-docs.txt | 2 +- proposals/ideas/old/xxx-geoip-survey-plan.txt | 137 +++++++++++++++++++++++++ proposals/ideas/xxx-geoip-survey-plan.txt | 137 ------------------------- 4 files changed, 140 insertions(+), 140 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 48ec6a8..91c2f27 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -86,7 +86,7 @@ Proposals by number: 163 Detecting whether a connection comes from a client [OPEN] 164 Reporting the status of server votes [OPEN] 165 Easy migration for voting authority sets [OPEN] -166 Including Network Statistics in Extra-Info Documents [ACCEPTED] +166 Including Network Statistics in Extra-Info Documents [CLOSED] 167 Vote on network parameters in consensus [CLOSED] 168 Reduce default circuit window [OPEN] 169 Eliminate TLS renegotiation for the Tor connection handshake [SUPERSEDED] @@ -137,7 +137,6 @@ Proposals by status: 140 Provide diffs between consensuses [for 0.2.2.x] 147 Eliminate the need for v2 directories in generating v3 directories [for 0.2.1.x] 157 Make certificate downloads specific [for 0.2.1.x] - 166 Including Network Statistics in Extra-Info Documents [for 0.2.2] 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion 174 Optimistic Data for Tor: Server Side @@ -179,6 +178,7 @@ Proposals by status: 148 Stream end reasons from the client side should be uniform [in 0.2.1.9-alpha] 150 Exclude Exit Nodes from a circuit [in 0.2.1.3-alpha] 152 Optionally allow exit from single-hop circuits [in 0.2.1.6-alpha] + 166 Including Network Statistics in Extra-Info Documents [for 0.2.2] 167 Vote on network parameters in consensus [in 0.2.2] SUPERSEDED: 112 Bring Back Pathlen Coin Weight diff --git a/proposals/166-statistics-extra-info-docs.txt b/proposals/166-statistics-extra-info-docs.txt index ab2716a..8b0c6a1 100644 --- a/proposals/166-statistics-extra-info-docs.txt +++ b/proposals/166-statistics-extra-info-docs.txt @@ -3,7 +3,7 @@ Title: Including Network Statistics in Extra-Info Documents Author: Karsten Loesing Created: 21-Jul-2009 Target: 0.2.2 -Status: Accepted +Status: Closed Change history: diff --git a/proposals/ideas/old/xxx-geoip-survey-plan.txt b/proposals/ideas/old/xxx-geoip-survey-plan.txt new file mode 100644 index 0000000..49c6615 --- /dev/null +++ b/proposals/ideas/old/xxx-geoip-survey-plan.txt @@ -0,0 +1,137 @@ + + +Abstract + + This document explains how to tell about how many Tor users there + are, and how many there are in which country. Statistics are + involved. + +Motivation + + There are a few reasons we need to keep track of which countries + Tor users (in aggregate) are coming from: + + - Resource allocation. Knowing about underserved countries with + lots of users can let us know about where we need to direct + translation and outreach efforts. + + - Anticensorship. Sudden drops in usage on a national basis can + indicate the arrival of a censorious firewall. + + - Sponsor outreach and self-evalutation. Many people and + organizations who are interested in funding The Tor Project's + work want to know that we're successfully serving parts of the + world they're interested in, and that efforts to expand our + userbase are actually succeeding. So do we. + +Goals + + We want to know approximately how many Tor users there are, and which + countries they're in, even in the presence of a hypothetical + "directory guard" feature. Some uncertainty is okay, but we'd like + to be able to put a bound on the uncertainty. + + We need to make sure this information isn't exposed in a way that + helps an adversary. + +Methods for current clients: + + Every client downloads network status documents. There are + currently three methods (one hypothetical) for clients to get them. + - 0.1.2.x clients (and earlier) fetch a v2 networkstatus + document about every NETWORKSTATUS_CLIENT_DL_INTERVAL [30 + minutes]. + + - 0.2.0.x clients fetch a v3 networkstatus consensus document + at a random interval between when their current document is no + longer freshest, and when their current document is about to + expire. + + [In both of the above cases, clients choose a running + directory cache at random with odds roughly proportional to + its bandwidth. If they're just starting, they know a XXXX FIXME -NM] + + - In some future version, clients will choose directory caches + to serve as their "directory guards" to avoid profiling + attacks, similarly to how clients currently start all their + circuits at guard nodes. + + We assume that a directory cache can tell which of these three + categories a client is in by the format of its status request. + + A directory cache can be made to count distinct client IP + addresses that make a certain request of it in a given timeframe, + and total requests made to it over that timeframe. For the first + two cases, a cache can get a picture of the overall + number and countries of users in the network by dividing the IP + count by the probability with which they (as a cache) would be + chosen. Assuming that our listed bandwidth is such that we expect + to be chosen with probability P for any given request, and we've + been counting IPs for long enough that we expect the average + client to have made N requests, they will have visited us at least + once with probability P' = 1-(1-P)^N, and so we divide the IP + counts we've seen by P' for our estimate. To estimate total + number of clients of a given type, determine how many requests a + client of that type will make over that time, and assume we'll + have seen P of them. + + Both of these numbers are useful: the IP counts will give the + total number of IPs connecting to the network, and the request + counts will give the total number of users on the network at any + given time. + + Notes: + - [Over H hours, the N for V2 clients is 2*H, and the N for V3 + clients is currently around H/2 or H/3.] + + - (We should only count requests that we actually intend to answer; + 503 requests shouldn't count.) + + - These measurements should also be taken at a directory + authority if possible: their picture of the network is skewed + by clients that fetch from them directly. These clients, + however, are all the clients that are just bootstrapping + (assuming that the fallback-consensus feature isn't yet used + much). + + - These measurements also overestimate the V2 download rate if + some downloads fail and clients retry them later after backing + off. + +Methods for directory guards: + + If directory guards are in use, directory guards get a picture of + all those users who chose them as a guard when they were listed + as a good choice for a guard, and who are also on the network + now. The cleanest data here will come from nodes that were listed + as good new-guards choices for a while, and have not been so for a + while longer (to study decay rates); nodes that have been listed + as good new-guard choices consistently for a long time (to get a + sample of the network); and nodes that have been listed as good + new-guard choices only recently (to get a sample of new users and + users whose guards have died out.) + + Since directory guards are currently unspecified, we'll need to + make some guesses about how they'll turn out to work. Here are + a couple of approaches that could work. + - We could have clients pick completely new directory guards on + a rolling basis every two months or so. This would ensure + that staying as a guard for a while would be sufficient to + see a sample of users. This is potentially advantageous for + load-balancing the network as well, though it might lose some + of the benefits of directory guard. We need to quantify the + impact of this; it might not actually make stuff worse in + practice, if most guards don't stay good guards for a month + or two. + + - We could try to collect statistics at several directory + guards and combine their statisics, but we would need to make + sure that for all time, at least one of the directory guards + had been recommended as a good choice for new guards. By + looking at new-IP rates for guards, we could get an idea of + user uptake; for looking at old-IP decay rates, we could get + an idea of turnover. This approach would entail significant + complexity, and we'd probably need to record more information + than we'd really like to. + + diff --git a/proposals/ideas/xxx-geoip-survey-plan.txt b/proposals/ideas/xxx-geoip-survey-plan.txt deleted file mode 100644 index 49c6615..0000000 --- a/proposals/ideas/xxx-geoip-survey-plan.txt +++ /dev/null @@ -1,137 +0,0 @@ - - -Abstract - - This document explains how to tell about how many Tor users there - are, and how many there are in which country. Statistics are - involved. - -Motivation - - There are a few reasons we need to keep track of which countries - Tor users (in aggregate) are coming from: - - - Resource allocation. Knowing about underserved countries with - lots of users can let us know about where we need to direct - translation and outreach efforts. - - - Anticensorship. Sudden drops in usage on a national basis can - indicate the arrival of a censorious firewall. - - - Sponsor outreach and self-evalutation. Many people and - organizations who are interested in funding The Tor Project's - work want to know that we're successfully serving parts of the - world they're interested in, and that efforts to expand our - userbase are actually succeeding. So do we. - -Goals - - We want to know approximately how many Tor users there are, and which - countries they're in, even in the presence of a hypothetical - "directory guard" feature. Some uncertainty is okay, but we'd like - to be able to put a bound on the uncertainty. - - We need to make sure this information isn't exposed in a way that - helps an adversary. - -Methods for current clients: - - Every client downloads network status documents. There are - currently three methods (one hypothetical) for clients to get them. - - 0.1.2.x clients (and earlier) fetch a v2 networkstatus - document about every NETWORKSTATUS_CLIENT_DL_INTERVAL [30 - minutes]. - - - 0.2.0.x clients fetch a v3 networkstatus consensus document - at a random interval between when their current document is no - longer freshest, and when their current document is about to - expire. - - [In both of the above cases, clients choose a running - directory cache at random with odds roughly proportional to - its bandwidth. If they're just starting, they know a XXXX FIXME -NM] - - - In some future version, clients will choose directory caches - to serve as their "directory guards" to avoid profiling - attacks, similarly to how clients currently start all their - circuits at guard nodes. - - We assume that a directory cache can tell which of these three - categories a client is in by the format of its status request. - - A directory cache can be made to count distinct client IP - addresses that make a certain request of it in a given timeframe, - and total requests made to it over that timeframe. For the first - two cases, a cache can get a picture of the overall - number and countries of users in the network by dividing the IP - count by the probability with which they (as a cache) would be - chosen. Assuming that our listed bandwidth is such that we expect - to be chosen with probability P for any given request, and we've - been counting IPs for long enough that we expect the average - client to have made N requests, they will have visited us at least - once with probability P' = 1-(1-P)^N, and so we divide the IP - counts we've seen by P' for our estimate. To estimate total - number of clients of a given type, determine how many requests a - client of that type will make over that time, and assume we'll - have seen P of them. - - Both of these numbers are useful: the IP counts will give the - total number of IPs connecting to the network, and the request - counts will give the total number of users on the network at any - given time. - - Notes: - - [Over H hours, the N for V2 clients is 2*H, and the N for V3 - clients is currently around H/2 or H/3.] - - - (We should only count requests that we actually intend to answer; - 503 requests shouldn't count.) - - - These measurements should also be taken at a directory - authority if possible: their picture of the network is skewed - by clients that fetch from them directly. These clients, - however, are all the clients that are just bootstrapping - (assuming that the fallback-consensus feature isn't yet used - much). - - - These measurements also overestimate the V2 download rate if - some downloads fail and clients retry them later after backing - off. - -Methods for directory guards: - - If directory guards are in use, directory guards get a picture of - all those users who chose them as a guard when they were listed - as a good choice for a guard, and who are also on the network - now. The cleanest data here will come from nodes that were listed - as good new-guards choices for a while, and have not been so for a - while longer (to study decay rates); nodes that have been listed - as good new-guard choices consistently for a long time (to get a - sample of the network); and nodes that have been listed as good - new-guard choices only recently (to get a sample of new users and - users whose guards have died out.) - - Since directory guards are currently unspecified, we'll need to - make some guesses about how they'll turn out to work. Here are - a couple of approaches that could work. - - We could have clients pick completely new directory guards on - a rolling basis every two months or so. This would ensure - that staying as a guard for a while would be sufficient to - see a sample of users. This is potentially advantageous for - load-balancing the network as well, though it might lose some - of the benefits of directory guard. We need to quantify the - impact of this; it might not actually make stuff worse in - practice, if most guards don't stay good guards for a month - or two. - - - We could try to collect statistics at several directory - guards and combine their statisics, but we would need to make - sure that for all time, at least one of the directory guards - had been recommended as a good choice for new guards. By - looking at new-IP rates for guards, we could get an idea of - user uptake; for looking at old-IP decay rates, we could get - an idea of turnover. This approach would entail significant - complexity, and we'd probably need to record more information - than we'd really like to. - -

1 0

r24287: {translation} documenting the workflow for all of our translation projects (translation/trunk/documentation)
by Runa Sandvik 02 Mar '11

02 Mar '11

Author: runa Date: 2011-03-02 15:46:57 +0000 (Wed, 02 Mar 2011) New Revision: 24287 Modified: translation/trunk/documentation/howto.txt Log: documenting the workflow for all of our translation projects, work in progress Modified: translation/trunk/documentation/howto.txt =================================================================== --- translation/trunk/documentation/howto.txt 2011-03-02 15:26:23 UTC (rev 24286) +++ translation/trunk/documentation/howto.txt 2011-03-02 15:46:57 UTC (rev 24287) @@ -1,32 +1,338 @@ -## Instructions for helping translate text for Vidalia, TorButton -## and TorCheck -## ( More translation information for Tor related apps will accumulate here ) +# This file documents the translation process for all projects +# currently available in the Tor translation portal: +# +# *. BridgeDB +# *. GetTor +# *. Vidalia Help Files +# *. Vidalia Installer +# *. Vidalia +# *. Orbot +# *. Torbutton-alpha +# *. Torbutton +# *. Torcheck +# *. The Website +# * Tor Manual Pages +# +# ( More translation information for Tor related apps and documentation +# will accumulate here ) -Our translations are handled in one of two places. The Tor Translation Portal -handles all of the translations for Vidalia, Torbutton and TorCheck. The Tor -website itself is currently handled by hand translations using subversion. -------------------------------------------------------------------------- +About Transifex: -For the Tor website, you'll need a Tor SVN account. -If you do not have one and you need one, please run this command with your -desired username in place of 'USERNAME': - htdigest -c passwd.tmp "Tor subversion repository" USERNAME -and send us the contents of passwd.tmp. + All of the translation projects are located here: + https://www.transifex.net/projects/p/torproject/. -------------------------------------------------------------------------- + Transifex is a website that lets users contribute translations + online using their web browser. Users will have to register at + https://www.transifex.net/accounts/register/ before they can start + translating. -For the Portal-based projects, all three check in their respective .po -files into the following subversion urls: + A project may have many files that can be translated. In transifex, + these files are called resources. Transifex lists all sentences or + phrases (called "strings") used by a particular resource, and allows + interested volunteers to translate individual sentences or phrases + as they are able. - https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton - https://tor-svn.freehaven.net/svn/translation/trunk/projects/torcheck - https://svn.vidalia-project.net/svn/vidalia/trunk/src/vidalia/i18n/ +The Transifex Client: -The current pootle configuration is checked into subversion as well: + The Transifex Command-line Client enables you to easily manage your + translations within a project without the need of a GUI. You can use + the command line client to easily create new resources, map local + files to translations and synchronize translation projects with your + local repository and vice verca. - https://tor-svn.freehaven.net/svn/translation/trunk/pootle + For more information about the Transifex client, see + http://help.transifex.net/user-guide/client/index.html#user-client + 1. Installing the client + + The Transifex Client can be found on the Python Package Index + (PYPI) under the name transifex-client. So to install it, make sure you + have a recent version of setuptools installed and then issue the + following command: + + $ easy_install -U transifex-client + + This command will install the latest version of transifex-client + and if you have an outdated version it’ll perform an update. + + 2. Init + + After installing the client, you will need to run the command + below to initialize a project and generate your own config file. + You may run this command from anywhere on your filesystem: + + $ tx init + + NOTE: You will be asked to enter the URL of the Transifex + instance you wish to connect to. Make sure it says + "https://www.transifex.net". + + The init command will create the following files for you: + ~/.tx/config and ~/.transifexrc. Each of the translation projects + have their own configuration file, so you can safely delete + ~/.tx/config. The other file, ~/.transifexrc, holds your username + and password for Transifex. + + 3. Set + + The following command is an aggregation of all functions needed + to initialize and setup a new translation resource: + + $ tx set + + For more information and other examples, see + http://help.transifex.net/user-guide/client/index.html + + As an example, here's how you would initialize and set up Orbot + as a new translation resource. + + Check out the Orbot translation directory from SVN: + https://svn.torproject.org/svn/translation/trunk/projects/orbot/. + + Inside the 'po' directory, run the following command to + initialize the new resource: + + ~/translation/projects/orbot/po$ tx init + + Once that is done, you can create the resource 'orbot-strings-pot' + and assign a source file: + + ~/translation/projects/orbot/po$ tx set --source -r torproject.orbot-strings-pot -l en strings.pot + + Once you have created a mapping between a source file and a + resource, you should add more translations to this resource. To + set a specific file as the source and auto-detect translations + for all languages, run the following command: + + ~/translation/projects/orbot/po$ tx set --auto-local -r torproject.orbot-strings-pot '<lang>/strings.po' --source-lang en --source-file strings.pot + + The Transifex client will store this information in the following + file: /translation/projects/orbot/po/.tx/config. + + To check the existing mapping of source files and translations, run the following command: + + ~/translation/projects/orbot/po$ tx status + + When you have assigned all of the source files and added all + existing translations, push the changes up to the Transifex + server (see below for information on how to push local changes). + Remember to commit the .tx/config file to SVN. + + NOTE: you can also initialize and setup new translation resources + on https://www.transifex.net/. + + 4. Push + + The following command sends local changes to the Transifex server: + + $ tx push [-s|--source or -t|--translations] + + If you have added new source files, the corresponding resources + are created on the Transifex server and if you have new + translations those will get pushed as well. This can also be used + to update existing source files or translations on the server + with new strings. Use --help for more information. + + NOTE: All translation resources have been configured to + automatically update the source files from URL. It is not + necessary to push the source files manually. + + 5. Pull + + The following command pdates your local files by pulling the + latest translations from the server as well as new translation + files that were created in the Transifex UI: + + $ tx pull + + By default, this command will check if the modification time of + your local files is more recent than that on the Transifex server + and will not overwrite newer files. Use --help for more + information. + + +BridgeDB: + + # TODO: document the translation workflow for BridgeDB when we have + # figured it out. + +GetTor: + + # TODO: document the translation workflow for GetTor when we have + # figured it out. + +Vidalia Help Files: + + The Transifex configuration file, source files and translations can + be found here: + https://svn.torproject.org/vidalia/vidalia/trunk/src/vidalia/help/content/. + + 1. Pulling Translations from the Transifex Server + + To pull new translations from the server, cd to the 'po' + directory and run 'tx pull'. Remember to commit the changes to + SVN. + + 2. Converting Translations to HTML + + Simply pulling translations from the Transifex server is not + enough. To make use of the translations, you will need to convert + the .po files to .html files. + + You can use the following script to automate the process: + https://svn.torproject.org/vidalia/vidalia/trunk/src/vidalia/help/content/p… + + NOTE: You need to have the package 'po4a' installed before running the script. + + 3. Creating/Updating Translation Template Files + + To create a .pot file from an .html file, run the following command: + + $ po4a-gettextize -f html -m file.html -p file.pot + + You will need to edit the header of the .pot file once it has + been created. Use the header from one of the existing .pot files + in 'po/templates' as a template. Remember to commit the file to + SVN. + + 4. Adding New Translation Resources to Transifex + + To add new translation resources to Transifex, open up + 'po/.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. + + 5. Pushing Files to the Transifex Server + + To push new/updated source files or translations to the Transifex + server, cd to the 'po' directory and run 'tx push' with either + '-s' or '-t'. + +Vidalia Installer: + + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/vidalia/vidalia/trunk/pkg/win32/po/. + + 1. Pulling Translations from the Transifex Server + + To pull new translations from the server, run 'tx pull'. Remember + to commit the changes to SVN. + + 2. Converting Translations + + # TODO: document how to convert translations to a useful format. + + 3. Creating/Updating Translation Template Files + + # TODO: document how to convert from a useful format to .pot + + 4. Adding New Translation Resources to Transifex + + To add new translation resources to Transifex, open up + '.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. + + 5. Pushing Files to the Transifex Server + + To push new/updated source files or translations to the Transifex, + simply run 'tx push' with either '-s' or '-t'. + +Vidalia: + + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/vidalia/vidalia/trunk/src/vidalia/i18n/po/. + + 1. Pulling Translations from the Transifex Server + + To pull new translations from the server, run 'tx pull'. Remember + to commit the changes to SVN. + + 2. Converting Translations + + # TODO: document how to convert translations to a useful format. + + 3. Creating/Updating Translation Template Files + + # TODO: document how to convert from a useful format to .pot + + 4. Adding New Translation Resources to Transifex + + To add new translation resources to Transifex, open up + '.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. + + 5. Pushing Files to the Transifex Server + + To push new/updated source files or translations to the + Transifex, simply run 'tx push' with either '-s' or '-t'. + +Orbot: + + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/orbot/po/. + + 1. Pulling Translations from the Transifex Server + + To pull new translations from the server, run 'tx pull'. Remember + to commit the changes to SVN. + + 2. Converting Translations to XML + + Simply pulling translations from the Transifex server is not + enough. To make use of the translations, you will need to convert + the .po files to .xml files. + + Start by checking out the following directory: + https://svn.torproject.org/svn/projects/android/trunk/Orbot/. + + You can use the following script to convert translated .po files to .xml files:: + https://svn.torproject.org/vidalia/vidalia/trunk/src/vidalia/help/content/p… + + NOTE: You need to have the package 'po4a' installed before running the script. + + 3. Creating/Updating Translation Template Files + + To create a .pot file from an .xml file, run the following + command: + + $ po4a-gettextize -f xml -m file.xml -p file.pot + + You will need to edit the header of the .pot file once it has + been created. Use the header from one of the existing .pot files + in 'orbot/po/templates' as a template. Remember to commit the + file to SVN. + + 4. Adding New Translation Resources to Transifex + + To add new translation resources to Transifex, open up + '.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. + + 5. Pushing Files to the Transifex Server + + To push new/updated source files or translations to the + Transifex, simply run 'tx push' with either '-s' or '-t'. + +Torbutton and Torbutton-alpha: + + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/torbutton/ + and here: + https://svn.torproject.org/svn/translation/trunk/projects/torbutton-alpha/. + + 1. Pulling Translations from the Transifex Server + + To pull new translations from the server, run 'tx pull'. Remember + to commit the changes to SVN. + + + + + ---------------------------- TorCheck ------------------------------- TorCheck uses our translation portal to accept translations. Users use

1 0