User talk:Mako Nozaki

Welcome

I just wanted to welcome to the wiki. It looks like you are doing a good job, keep it up. ^_^ -- Strife ^{(talk|contribs)} 06:06, 10 April 2010 (UTC)

Thanks:) -- Mako Nozaki 15:14, 13 April 2010 (UTC)

I'd like to second Strife's remark. That's pretty impressive work you're doing here!! :)

Since you also seem to be one of the more tech-savvy Residents, I was curious for your opinion: Do you consider "true/false" being "正/誤" in the デバッグ設定(Debug Settings) a bug or a feature?

Way to go! :D

--

^{(talk|contribs)} 03:51, 25 April 2010 (UTC)

Thanks Zai:) About Debug Settings, I checked in the viewer setting Japanese as XUI language, it shows actually 正/誤 in the True/False option. In my sense of native Japanese programmer, I find it a bit odd, prefer 真/偽 or rather True/False (Most of Japanese know these term), but the viewer is already in public with these terms for a long time, so can't be helped. By the way, there are not a little mistranslations or odd translations especially in viewer 2, but when I create the wiki translation, I copy and paste them as-is shrugging:p Mako 04:17, 25 April 2010 (UTC)

Welcome! ^_^

Ah yeah, leaving as True/False was, what I was curious about... When you stumble upon odd/weird translations in V2, I'm sure Rika would be happy to hear about them! The V2 translation happened as part of the Community Translation Project with a small group of Residents. I participated in the German translation, but can tell that it's sometimes rather difficult to find the correct term, when you're just looking at an xml file and lacking the context. So any help is appreciated, in order to polish the localization for the next release! :)

There is a Japanese localization meta-issue in the JIRA, which was created for the beta. I think it's still OK to add child issues there. It's VWR-17475.

Anyway, glad you're around!

WikiLove,

^{(talk|contribs)} 07:29, 25 April 2010 (UTC)

RE: https://wiki.secondlife.com/w/index.php?title=Template:LSL_Function/ja&curid=10188&diff=853412&oldid=853222

You might want to instead rename the categories to something that are meaningful in Japanese, instead of forcing them to be internationalized English titles. -- Strife ^{(talk|contribs)} 18:14, 12 April 2010 (UTC)

Thank you for advice Strife:) But many of categories have been already created with the name of such format... It would be difficult to fix them... I'm thinking inserting conversion of category name in LSL_Header/ja, which will have a map of Japanese name and XXX/ja, after finishing catching up with English pages. -- Mako Nozaki 15:17, 13 April 2010 (UTC)

About Template:LSL ConstRow

Once upon a time I had this great idea: make it so constant information can be accessed via template call. The devil was in the details. It was too costly to implement for PrimitiveParams. Sure I could have centralize the constant information but it would have been too difficult to edit. Eventually the project was shelved but before that happened Template:LSL ConstRow was written and deployed assuming the functionality would be provided. There is no harm in using it but it really should have been streamlined when work halted. I'm pretty sure the template would not have worked properly considering changes made in 1.13 to the parser (or was it 1.14?). -- Strife ^{(talk|contribs)} 06:22, 17 April 2010 (UTC)

I see. I guessed you were trying to provide the constant assignment expression on the tooltip when I looked at it. I can't just ignore the semicolon at the end of string on it, and it was the only reason I tried to modify the template, so it is ok:) Anyway, cool template -- Mako Nozaki 06:43, 17 April 2010 (UTC)

Another facet of the project is to provide tooltips for function links. A few months ago I figured out a way to make the project work (more or less). Every template that exists outside of the layout template call needs to be moved into a parameter of the call. Seeing as this is a huge amount of work, it remains on the back burner. But as I go through the articles I'm updating them to use the new "inject-x" parameters (which are actually an improvement, not just a means to an end; they solve a chicken-and-egg problem). It will probably be 6 months to a year before we see tooltips and automated descriptions in the link tables. -- Strife ^{(talk|contribs)} 09:05, 17 April 2010 (UTC)

Template:Interval internationalizations‎

I've updated Template:Interval, it tries to include the international version of Template:Interval/Footnote if it can find it; if it can't it falls back to the english version. The additional parser cost is trivial. -- Strife ^{(talk|contribs)} 09:05, 17 April 2010 (UTC)

Thanks. I removed Interval/Footnote/ja include from PRIM TYPE BOX/ja template. It looks like that now --> PRIM TYPE BOX/ja It seems to succeed in including Interval/Footnote/ja from Interval template. Except that I can't see where the footnote indicates, it's not bad. -- Mako Nozaki 11:13, 17 April 2010 (UTC)

copyok?

What does "copyok" mean? The name looks to have little to nothing to do with the caveats it silences.
Are you saying that it doesn't show an error and the functions fail silently OR are you saying that it doesn't fail. You have added ambiguities by not replacing the caveats with alternative text.

These edits leave me with serious reservations, without some explanation of them I'm left doubting their accuracy. -- Strife ^{(talk|contribs)} 09:26, 5 May 2010 (UTC)

Before editing, there were two conflicted messages in caveats of LlGiveInventory and [[LlGiveInventoryList : "If item cannot be copied then an error is shouted on DEBUG_CHANNEL. " and "If inventory is no-copy the item is transfered to destination without copying it. Since it is no-copy the only copy is given to destination; removing it from the prim's inventory. " -- My intention was only remove the former when the users look at those two functions... Thanks. --Mako 09:48, 5 May 2010 (UTC)

Ahh i see. The functionality is more complicated then that. llGiveInventory and llGiveInventoryList work differently. Last time I checked, llGiveInventory can transfer no-copy items but llGiveInventoryList cannot (not a feature people like). I know there are some jiras on the issue but it's been a while since I've looked over them and I'm not sure if anything has changed on that front. As you point out, there is something wrong with the caveats and it looks like I'm going to have to review those jiras to straighten everything out. *sigh* -- Strife ^{(talk|contribs)} 05:38, 6 May 2010 (UTC)

Reviewing LlGiveInventoryList, I noticed there were no mention of no-copy object in descriptions and the sample said as if it can't transfer no-copy object, so I removed copyok flag from that article. Sorry for confusing you. On the other hand, the article of LlGiveInventory says it can transfer no-copy object. Personally I don't think that as terrible functional issue, I'm just reviewing whole article if there is any discrepancy or duplication in explanations:) --Mako 10:07, 6 May 2010 (UTC)

Bumper cars

I would have never guessed there aren't bumper cars in Japan. -- Strife ^{(talk|contribs)} 06:50, 8 May 2010 (UTC)

Hehe:) In fact, there are bumper car in Japan as well, but not so many people know it is called "Bumper Car", it would be called "Boo-Boo" or so, or considered as the same as just an open (mini) car. --Mako 06:56, 8 May 2010 (UTC)

Oh thats good to know. This will be the last time I use the absence of an article to be the base of an assumption. -- Strife ^{(talk|contribs)} 06:02, 9 May 2010 (UTC)

Your feedback

Hi Mako,
Thanks for your feedback! Yeah, the workflow is a bit cumbersome at the moment. All translated articles are protected and handeled via pJIRA. We (Localization Team) have just recently been able to separate articles with sensitive information (LLO) from the other articles. That step allows us to think about the transition to a review system for article contributions, like it's already done for the English non-LLO articles. We're currently discussing best ways to ensure that articles are kept in sync with the English source. So the item is on the agenda and I hope that it will soon be easier for you to make contributions to the Japanese KB articles as well. I've seen you adding many useful LSL- and Help Portal translations and want to take this opportunity to thank you for them. When you got any questions about (or suggestions for) the CT Projects, don't hesitate to forward them to me any time :)
Happy editing to you too! --Khepri Contractor 17:42, 13 May 2010 (UTC)

Please stop editing the wiki

It is going to take a lot of work to (unless I just undo your last 50 edits) to fix the mess you just made. Have you actually tested any of the claims you have made? Have you ever run a script or been in-world? Before posting about a caveat or bug or example... I TEST for hours. The information is then CORRECT. Your use of English leaves a lot to be desired and much of what you write is not only inaccurate but difficult to understand. I dread to think what Japanese users are being told. -- Fred Gandt ^{(talk|contribs)} 12:02, 22 May 2010 (UTC)

Sure. I've tested them for all a day with the script you and other editors have posted. If you think it is inaccurate, or too difficult for reading, feel free to edit them. It's the wiki for everyone can freely write and edit them:) But I think undoing all of them isn't mature way... You might want to read Editing_Guidelines again. Thanks and happy editing:) -- Mako 12:07, 22 May 2010 (UTC)

Sublime Text 2:

Greetings, this might help you to update your LSL syntax for Sublime Text 2.

for the LSL plist file:

The information should be exact as of 2012-11-09 with all latest additions to LSL. Feel free to delete this noise when you took your copy to update the Sublime Text 2 syntax, lol! Have a nice day -- Kireji Haiku 10:12, 4 December 2012 (PST)

Thank you for your feedback:) For now, two comments on your completion file suggestion:

Yours includes "SERVER_COST", however, as long as I have looked in wiki and source codes, there isn't. Instead, "OBJECT_SERVER_COST" is used in llGetObjectDetails.
I excluded and marked llCollisionSprite() as to-be-avoided since llCollisionSprite says it is broken and VWR-322 doesn't seem to be solved(closed).

I'll later on look in my language file if I have missed anything. -- Mako 03:39, 6 December 2012 (PST)