%s cannot be repeated as far as I know.

When multiple variants exist, should we export a nested structure like this?

[...]

"aBmeIEk": {
    "one": "%s star",
    "other": "%s stars"
},

In T5267#199335, @epriestley wrote:

Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.

At least some translators are likely familiar with $1, {{GENDER:$1|X|Y}}, and so on, right? And you have documentation on this syntax to help translators who aren't familiar with it learn it?

you can check this page, it is original phabricator page, it also cannot show in my server.
maybe the remarkup engine cannot work in my server, i don't know how to resolve it.

Here are the current internal data formats:

Could you tell me how to check the server error?
i don't find the errors on server.

Ah yea my hypothesis doesn't make 100% sense given all the rest of the text in your screenshot. Are there errors on the server?

i attached my saved webpage. The Text isn't existed the source code.

In T6653#167413, @maccath wrote:

For reference and the benefit of people Googling how to configure a script and regex linter, here is a full example (using sass-lint):

.arcconfig file:

{
"linters": {
    // snip ...
    "sass": {
          "type": "script-and-regex",
          "include": "(\\.scss$)",
          "script-and-regex.script": "sh -c 'sass-lint -v \"$0\" || true'",
          "script-and-regex.regex": "(^((?P<file>.+): line (?P<line>[0-9]+), col (?P<col>[0-9]+), (?P<severity>[^\\-]*) - (?P<message>.*) \\((?P<name>[a-z\\-]+)\\))$)m"
    }
}

Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.

I don't know a thing about the web but looks like it might be a font issue. Presumably your setup has the monospaced font available for use in codeblocks, but not the regular text one.

I'll have to update my instance first to test your patch, since it seems to be for newer version as you said earlier. I installed this from FreeBSD ports system, have to first convert it to normal git based install.

Some of the terms that I use below (e.g. outdated) are explained in https://www.mediawiki.org/wiki/Help:Extension:Translate/Glossary

I am very sorry! please delete it.

Thanks for looking into the profile. The queuing I think fixes the issue with speed of importing. The next thing I was going to try was auto-import of the .ics file from a hosted location on hourly basis, and I'm assuming there's no proper way to only query for the newest things (at least though the API in Zimbra I've found) - so Phabricator would have to process the file every request. With queuing it shouldn't matter.

Here's the XHProf link:

This self-healed (probably after another commit was pushed) so I don't expect to look at it for a while unless it happens again.

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• Sorry, I've dropped my bag of Doritos™ brand perfect circles • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •• • • •• • • • • • • •

The color should be fixed by D16819.

@epriestley nope, as you can see in my last screenshot the Nov 8 event doesn't have any edits in the transaction log. We don't use any third-party app to edit the calendar, just the Phabricator UI.

So far the pup is sleeping a lot and doing very little mischief.

At HEAD, I think the all-day issues with the French holidays above are fixed. You may need to reload the import for the change to take effect, but things seem OK for me locally now:

Ah, cool. I think that's a Zimbra issue, then.

@ivo, that's expected if you previously edited the Nov 8 instance. This is consistent with Calendar.app, although not with Google Calendar.

I checked for that UID and there are exactly two events, both with "RECURRENCE-ID":

RECURRENCE-ID;TZID="America/New_York":20130528T150000

(mindrot.org is currently inaccessible for me so I wasn't able to read the details you linked, although I imagine they aren't too relevant to how we handle things.)

I was trying to import the french holidays from google ICS file...

The rTRANSLATEWIKI repository is now available. Here is an example of the en.json MediaWiki-style JSON string file we currently generate:

This isn't a bug. Here's an example of why the proposed behavior is dangerous:

I'd prefer not to produce any output until we've generated everything, so we don't end up in a situation where we output half of the file and then fail if we can help it. Additionally, this script changed in D16744, a few weeks ahead of your version.

Thank you for clarifying the behavior of the timeout. It wasn't clear to me whether I would wait for feedback after clicking the Reload button or begin refreshing the page. After the change to queuing of import the events were imported. I'm doing all this testing on a test instance of Phabricator so I would be able to add log/debug statements and re-import the calendar again to track down what might be slow. The import pulled in ~1700 events in ~3 minutes.

I don't know what this means. $ in the string contents isn't anything special for translatewiki.net.

• When exporting, I don't know how to escape $ for Translatewiki (this affects ~10 strings).

When changing the start and end dates on all future instances of an event, some of the future instances may keep the old dates.

Likewise, when importing, I don't know how to unescape $.

I was trying to import the french holidays from google ICS file : https://calendar.google.com/calendar/ical/fr.french%23holiday%40group.v.calendar.google.com/public/basic.ics

The technical definition of "Limited" is that it has fewer than 512 strings, including 0 strings.

In T5267#199144, @epriestley wrote:

• Did you notice that "Spanish (Spain)" was under the "Limited Translations" heading, instead of the "Translations" heading?

You should file a new bug report, describing exactly what you did and how we can reproduce the problem.

@epriestley where is the propper place then to help improving documentation?

To report a bug, please provide complete reproduction steps. We can't fix issues we can't reproduce. See Contributing Bug Reports for details.

I think D16810 should get this started, at least. Known technical issues:

@MZMcBride, couple of questions so we can improve this:

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works: