IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/11/10
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cumlord
+hk
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest22478
Irc2PGuest48042
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
acetone_
anon4
anu3
boonst
juoQuua9
mareki2pb
not_bob_afk
plap
poriori
shiver_1
simprelay
solidx66
thetia
tr
u5657
weko_
dr|z3d zzz: is that news item you've written re translators et al meant to be published?
zzz dr|z3d, published where?
dr|z3d console news, zzz
dr|z3d I thought that was the intention?
zzz no, it's up on the transifex announcements page
dr|z3d <dr|z3d> re poking the translators, might be an idea to publish a new item, reference the translations and the delay in the release.
dr|z3d <dr|z3d> *news
dr|z3d <zzz> sure, and ask for Persian updates
dr|z3d <zzz> done
zzz I'll leave that to idk if he wants to
dr|z3d I was suggesting a console news item, maybe I wasn't clear enough, to inform users of the reason for the delayed release and to invite new translators to the party, particularly farsi/persian translators, but ok.
dr|z3d eyedeekay: ^
zzz yes, it's his release, his PR, his schedule
zzz anybody know anything about "simplified chinese" ?
zzz and do we need it distinct from zh_CN and zh_TW?
zzz re: 151, thanks
dr|z3d yes, and yes.
dr|z3d if you wanted to reduce the translation burden, you could just opt for simplified chinese and (maybe) taiwanese chinese.
zzz why? who/where is the target audience?
dr|z3d simplified chinese will be understood by chinese speakers, probably taiwanese speakers too, though apparently there are some differences between chinese and taiwan chinese, though I doubt they're related to the techincal translations in the console.
dr|z3d this is the discussion I'm having with myself at the moment.. taiwanese chinese, portuguese brazilian and argentinian spanish all seem like they're a bit unnecessary.
zzz I want to know that it's distinct enough from the two we have and that there' a user base for it
dr|z3d you have the po files, diff them, see what stands out :)
zzz yeah the people that just copy es to es_AR and they're 100% identical is a total waste
zzz I'm asking because we have request on transifex to add simplified chinese. no we do not have po files or translators
dr|z3d ok, well at least that's settled then. nuke argentinian.
dr|z3d oh, I assumed the current translation _was_ simplified chinese.
zzz but what do I know, maybe there's one string that irks somebody because it's wrong in argentina
dr|z3d I'd have to ask Narratorz to get clarification on what's in +
zzz I don't know if it is or not
dr|z3d one string, haha.
zzz in transifex, simplified is zh-Hans so I don't even know how we'd support it. "simplified" and "Hans" are not country codes
dr|z3d > Chinese is a language that has multiple writing systems, including traditional Chinese and simplified Chinese. Simplified Chinese is a reform of the traditional Chinese script that was introduced in mainland China in the 1950s to increase literacy rates. Simplified Chinese characters have fewer strokes and are easier to write and read than traditional Chinese characters. However, traditional Chinese is still
dr|z3d used in many parts of the world, including Taiwan and Hong Kong.
zzz here's the message I sent to the last person that requested it, no reply:
zzz I saw your request for Chinese (Simplified) for I2P.
zzz We already have Chinese (China) and Chinese (Taiwan). Please help me understand what users or countries simplified Chinese is used for and if we really need another "flavor" of Chinese.
zzz that seems to imply that zh_CN is simplified, more or less
dr|z3d one would hope so. I'd be inclined to support just that, simplified chinese.
zzz no you can't just trash zh_CN and replace it with zh-Hans on transifex, we'd lose all our translations
zzz it's up to the translators what they put in zh_CN, maybe it's "simplified", maybe not, but we can't enforce that
dr|z3d just keep it as is and add a note to the transifex section saying that simplified is preferred when translating?
zzz I don't think I know enough to say that
zzz one guy claims he's working on simplified chinese now but we have no "simplified chinese" language approved, so that would imply that zh_CN is indeed simplified
zzz I'm going to deny the zh-Hans request
dr|z3d yeah, just nudge him over to the existing translation.
zzz he didn't reply to my query, so no nudging possible
zzz somebody could always request it again and make a case; but we'd have to know how to support it in our existing system
zzz if it comes up again I'll ask sadie to research it
dr|z3d looking at the + console translations, I'm reliably informed that it's using simplified chinese.
zzz ok good, I think we got to the bottom of it then
zzz so zh-Hans is rejected and will stay rejected
dr|z3d let's see what you got in canon.
dr|z3d yup, same, you haz simplified it appears.
zzz great, thanks
dr|z3d sure thing. just to clarify further, taiwanese chinese is a form of traditional chinese with differences from mainland traditional chinese.
dr|z3d taiwan, hong kong and macau all use traditional chinese, not simplified.
dr|z3d whether the differences between taiwanese chinese and simplified chinese are glaring and unintelligible enough to warrant a separate translation is yet to be determined.
dr|z3d but if you've got committed taiwanese translators, then I guess that answers the question.
zzz this happens several times a year, somebody requests ru or en_US or en_UK or zh-Hans, and it's reject reject reject
dr|z3d good. if it's just a minor spelling difference, what's the point? en_uk, bah.
zzz well, we added zh_TW a long time ago, so it's staying in. Once it goes in it's in
zzz but es_AR may have been my mistake ((
dr|z3d my source tells me argentinians won't have any major issues understanding (castilian) spanish, despite some minor differences.
zzz sure. I don't know if people know that you don't need es_AR because it will fall back to es. The problem is that I get almost zero response rate when I message ppl on tx asking 'why did you request this'
zzz sometimes I'll also send a message 'I rejected your request for ru, please use ru_RU, thanks for your help' but never get a response to that either
dr|z3d have you got a coverage threshold for inclusion? that might sort the wheat from the chaff. something like 70% for the console, 90% for everything else.
zzz it's not an automatic threshold but I sort by completion, eyeball it, and draw a line. it's more like 30%
zzz because I think partial translation will motivate more translators
dr|z3d yeah, that's one way of looking at it, but it leaves the console looking pretty shabby if most of the strings aren't translated.
zzz sure but needs to be functional. Just having the one-word buttons and links translated is enough to get people by
zzz and the machine translation fills in a lot of that for us on tx
dr|z3d sidebar and <h1>s also worth checking, even if you need to use machine translation.
zzz there's only so much we can do, there's 18 resources x 60 languages on tx. Can't review over 1k pairs on checkin deadline day
dr|z3d sure, it's a bit of a beast.
KernelHawk dr|z3d, zzz, Thoughts on an API for i2psnark?
KernelHawk would this conflict with the integration within the i2p router?
dr|z3d KernelHawk: there's already a sort-of api for snark, I say sort of, it uses RPC for which there's a plugin available.
KernelHawk Lemme check it out
zzz you're underselling it
dr|z3d pimp away, zzz :)
zzz not only is it a real API, it's a standard API
dr|z3d what are you hoping to achieve, KernelHawk? what's the use case? command line snark or something else?
KernelHawk Mainly to "simplify" the web-ui. Get messages as a JSON response and update the log using JS. And then possibly add API calls to add torrents remotely and stuff like that.
KernelHawk Basically expose all settings through the API
KernelHawk still looking through this RPC
dr|z3d you should be able to pull the log messages as json via ajax.
dr|z3d in the development builds of i2psnark/i2p+, you also have the screenlogs as a separate ajax-friendly page here: 127.0.0.1:7657/i2psnark/.ajax/xhrscreenlog.html
zzz nonono you're proposing he write a client that does mix and match to use both the transmission RPC and AJAX to your web ajax handlers.
zzz ewww
dr|z3d haha, no, not proposing anything. just saying, if he wants to "update the log using JS", the bones are already there.
dr|z3d in fact, the logs are already updated via JS, so maybe I'm not getting what KernelHawk is wanting to do there.
zzz ofc if the logs are not available via RPC because there's a transmission RPC call we don't support in the plugin, patch welcome
RN idk mentioned something about potentially making logs available via i2pcontrol
RN I presume if that is doable in i2pcontrol it would also be applicable to the i2psnar-rpc
zzz sure but only if transmission-cli supports it
RN ahhh
zzz because it's a more or less standard RPC API supported by transmission, vuze, azureus, ...
zzz so no use inventing our own extensions
RN gotcha
zzz fixed yer i2ptunnel bug today
RN the naming one?
dr|z3d y, RN, the naming one.
RN awesome! Thank you.
KernelHawk dr|z3d, I guess I'd be fixing a problem that isn't there. nvm :)
dr|z3d all depends what you want to do, KernelHawk
dr|z3d I vaguely recall someone a while back asking about a command line api for snark, not sure we have that.
zzz that's 'transmission-cli' + the RPC plugin
dr|z3d ok, then I guess we do have a command line api :)
zzz it's confusing, but the plugin both provides the RPC API usable by any compatible clients e.g. transmission-cli, AND an alternative web UI that uses that API
zzz transmission-remote I think also works
zzz actually I have it backwards
zzz transmission-remote is the thing
zzz transmission-cli is a standalone cli client
zzz man transmission-remote
RN very minimal mentions of "log/logging" in the tranmission api docs... not clear if it actually gets log entries, or just logs specific commands in its normal way.
RN just a parameter in a couple commands, no explanation
dr|z3d -88+ now uploaded with zzz's aforementioned tunnel naming fix, for those running dev builds of I2P+
RN \o/
RN shame it didn't make the cut for -11 but the other user is very happy to have the naming issue fixed in upcoming release. Thanks on their behalf zzz.
zzz i would have bumped it for you but I have to ask idk's permission ))
zzz dont worry we will bump again
RN yes, y'all have been quite busy lately. :D
RN giving my build script a workout
zzz trying to converge on something sane, secure, and internally consistent
RN I believe I see that happening in thoughtful stages.
zzz we're at the very last stage, the very bottom layers where things are opaque, where the problems aren't easy to find and we're staring at it line-by-line
zzz we've actually pivoted to more test development and testing