Messages

Hi Franco,

I just cleaned  up my repo, (I got pretty messy in there, hack hack hack...) don't need help with the repo itself though-

When I finish the EN base, I'll gladly submit the single file as a merge request, from this branch:
https://github.com/dotike/opnsense.core.ja_JP.UTF8/tree/locale.EN.canonical

--
Basic status is this:

I've now been through 3 or 4 full passes, catching all the big issues now- and it's just down to a race to finish the last manual pass through the English .pot file.

- The branch I'm working from is now 28 days old, and I'll need to check the diff for any relevant changes to the translation file.
(Incedentally, I found a number of odd gettext calls in the source which I'll address later)

- After a lot of slogging through the source code, I could generate much of the English .pot file content in an automated manner.  Yet, as with problems like this, comprehensive parsers take far longer to write than just editing the file- there are so many edge cases for how the strings are handled in the codebase.

Expected outcome: when I'm done with this pass, a functional .en POT file will be ready to push upstream, and I'll submit a pull request as soon as that's ready.  Yet, there will be a few things still to do from there:

--
When the English file is done:

- Japanese, (and any other languages) can begin translation work
- OPNsense core will want to maintain the English file, as the canonical base for all other languages
- The gettext machinery will need to be hooked up in to make it all work

Best,
.ike

The Volt template stuff is work in progress, if you want to have an idea of where this is heading you can look at the Proxy code which is under development.
- [/usr/local/]opnsense/mvc/app/models/OPNsense/Proxy/
- [/usr/local/]opnsense/mvc/app/controllers/OPNsense/Proxy/
- [/usr/local/]opnsense/mvc/app/views/OPNsense/Proxy/

I will post some notes on our wiki pages on how to enable the new code in the current environment, some develop information is already there.

Sounds good, thank you- I'll dig into it after I get through a first cut at fresh .pot files,

For the location of the new locale files for opnsense I would like to suggest the following base location:

/usr/local/opnsense/locale/

But if this location turns out to be less practical, I will refactor the code to make it work later on.

Hrm...  I *think* this sounds good, but I'm not up to speed on where 'core' layers in to 'src', (I haven't made time to build the whole thing yet).  For now, just to get working I put the files in:

[core]/src/share/locale/

https://github.com/dotike/opnsense.core.ja_JP.UTF8/tree/96aa0a8a29abd9deb6f68df7ebc4edc6ea1dbe4c/src/share/locale

I believe that it's wise to keep the gettext .pot files outside of the UNIX base hier(7), and instead, in the sort of 'core hier(7)'- that keeps it them neatly isolated away from system bits.  If /usr/local/opnsense/share is that spot, then it sounds great to me!

If you have some translation files for me, I will alter the path settings in the current codebase to make sure you can start easily.

Even though our target is Japanese, I'll have a completely fresh English .pot file done soon enough, generated fresh directly from every gettext call in the current OPNsense 'core' codebase.
Once I'm through the slog of getting it done, we'll all have something to work with- and other languages (Japanese) can go to town and start the translation work- without being blocked by aggressive changes in 'core'.

https://github.com/dotike/opnsense.core.ja_JP.UTF8/tree/96aa0a8a29abd9deb6f68df7ebc4edc6ea1dbe4c/src/share/locale/en/LC_MESSAGES

I hope to be done with it this week, and will toss yall' a pull request when it's sane- (it's just grunt work atm...)

Best,
.ike

Re-generating EN canonical .pot file, building from the ground up.
By the end, a completely fresh, and code-accurate .pot file will exist- (but will still need some hacking to make the UI php/gettext pick up the right .pot file)

The old .pot files were discarded, (fresh start for OPNsense), a new English gettext .pot file needs to be created as a canonical base, (for all other languages to follow).  Perhaps if other languages dominate, 'en' won't be canonical- but at the moment, it most certainly is.

再生成するゼロから構築、EN標準的な.POTファイルを。
年末までに、完全に新鮮な、とコードの正確な.POTファイルが既存します（まだUIのPHPを作るためにいくつかのハッキングが必要になります/右.POTファイルを拾うのgettext）

古い.POTファイルは、（新たなスタートOPNsense用）、（他のすべての言語が従うことのために）ファイル.POT新しい英語のgettextは、標準的なベースとして作成する必要があり、廃棄した。他の言語が支配している場合、おそらく、「EN」canonical-されませんが、現時点では、それは最も確かにある。

--
Before work can really be unleashed on JA translation, the EN base really needs to get done.
作業は本当にJA翻訳に解き放たれる前に、ENベースは本当に片付ける必要がある。

This en first pass is in progress here, I'll keep chipping at it as I can make time this week:
このEN最初のパスは、私はこの週時間を作ることができますように私はそれを欠けておこう、ここで進行中です。

https://github.com/dotike/opnsense.core.ja_JP.UTF8/commits/381eeb644fc223412e17927aff98a925f3477022/src/share/locale/en/LC_MESSAGES/OPNsense.pot

On the wiki page,

Additional suggestion for USB media install lines, the OpenBSD line is just how it works, but the MacOSX line is an optional (yet arguably more reliable) method.

--
OpenBSD:

  dd if=OPNsense-XXX-memstick-amd64.img of=/dev/rsd6c bs=16k

The device must be the ENTIRE device (in BSD language, the 'c' partition), and a raw I/O device (the 'r' in front of the device "sd6"), not a block mode device.

--
MacOSX

  sudo dd  if=OPNsense-XXX-memstick-amd64.img of=/dev/rdiskX bs=64k

where r = raw device, and where X = the disk device number of your CF card (check Disk Utility) (ignore the warning about trailing garbage - it's because of the digital signature)

全体OPNsenseプロジェクトにあった、すべてのJP翻訳作業のためのライセンスは、2条項BSDライセンスの下で落ちる必要があります。
In accord with the entire OPNsense project, the licence for all JP translation work should fall under the 2-clause BSD licence.

古いpfSense JPの翻訳作業の用語はambigiousであるため、そのことを、このOPNsenseの翻訳作業は、新鮮な開始されます。
With that, because the terms of the old pfSense JP translation work is ambigious, this OPNsense translation work will be starting fresh.


古い作品をここで参照することができます。
The old work can be referenced here:
https://raw.githubusercontent.com/pfsense/pfsense/07cf6e6e0454dc730f2916e54bbf2b9a569fc812/usr/local/share/locale/ja/LC_MESSAGES/pfSense.po
（Taguchiさんはほとんど重い翻訳作業のすべてをした！）
(Taguchi-san did almost all of the the heavy translation work!)

[ワークフロー | Workflow :]

こんにちは！  Welcome everybody!

OPNsenseの主催者のおかげで、新しい日本フォーラムが作成されました。
Thanks to the OPNsense organizers, a new Japanese forum has been created.

ワークフロー | Workflow :

メインプロジェクトの邪魔にならないように私たちの仕事を保つために、私は「仕事フォーク」を作成しました。我々は戻って引き渡すための翻訳作業ができたら、それはGitHubのプル要求 - を作成したり、gitのフォーマット - パッチ/ gitの-AMを使用してOPNsenseの人々へのパッチを送信することと同じくらい簡単なのです。
To keep our work out of the way of the main project, I have created a 'work fork'.  Once we have translation work to hand back over, it's as trivial as creating a github pull request- or sending patches to the OPNsense folks using git-format-patch/git-am.

https://github.com/dotike/opnsense.core.ja_JP.UTF8

参加したい場合は、このフォーラムに投稿するか、githubのリポジトリの協力者に連絡してください。
If you would like to contribute, please post to this forum, or contact the github repository collaborators.

Best,
.ike

Ad,

At the moment we don't have any other mechanisms in place for translation as there where in pfSense, but for the new components we're planning for a similar approach using language files (and hook it into a Volt template tag / supply some helpers for the ajax parts).

OK- interesting.  I have no idea what Volt templates are, I'll do some reading and see if I can grok it enough to help appropriately, (and not waste your time).

For the time being we've chosen to remove the language files, because we're not sure how complete they are and we're unable to validate the contents our selves.

Honestly, that's a good idea- the UI is a fresh start and new direction, the translations should be too.

And for the long-term, juggling to make sure the quality of the translations is "up to snuff", and tracks releases, becomes a different problem to tackle- we have discussed this for Japanese with several ideas to help automate human validation of changes over time- but too early for that talk now...

I guess that the language support still works for most parts when the translation files are placed inside the correct directory (gettext seems quite standard), but if that doesn't work I can look into it for you. It's very nice to hear that you want a Japanese version, so when I can help just let me know.

Oh!! Is there a place we can start with the .po files now?  That will kickstart getting the translation patches up to you fast, even if it's not the permanent place for the file.

(In pfSense, the english .po file was the base canonical reference for all other translations.)

When you have patches for the project,  just put a pull request on github and we'll place it in our standard release.  (as long as we may include them under the 2 clause bsd licence).

Delighted, and enthusiastically supporting the 2 clause bsd license for all work.

It's no problem to have a Japanese forum, I will open one for you right away.

どうもありがとう!  Thank you!

All Japanese specific talk I'll move over there, but I may post general internationalization implementation questions to this "main" list...

Best,
.ike

こんにちは、みんな、

このマシンベースの翻訳はご容赦ください。

私たちは前にpfSenseのためにそれをやった、OPNsenseの作業日本語訳を作ることになりました集中に熱心だが、それはまだ（下記注）、うまくいきませんでした。

- OPNsenseのユーザーインターフェイスの国際化の状態は何ですか？

- gettextを使用するための計画がありますか、または他のいくつかの計画はありますか？

- あなたの人々は、FreeBSD / SRC、良い仕事から離れて、それをせん断しているように私は、すべてのファイルの場所は、UIのために喜んでかなり異なっていることがわかります！しかし一方で、私は数の.jsファイル用の国際化ファイルを見つけることができます。 （ファイルリストは、レコードのため、以下に記載）。

- それは、日本国際フォーラムを追加することは可能ですか？

ありがとう！

ベスト、
.ike

Hi All,

We're eager to focus now on making a working Japanese translation for OPNsense, we did it for pfSense before, but it did not yet work out, (notes below).

- What's the state of internationalization in the OPNsense user interface?

- Is there a plan to use gettext, or is there some other plan?

- I see that all file locations are happily quite different for the UI, as you folks are shearing it away from FreeBSD /src, good work!  But in the meantime, I can only find internationalized files for a few .js files.  (File list noted below, for the record).

- Is it possible to add a Japanese International forum?

Thanks!

Best,
.ike





--
Our history:

Last year, the pfSense user interface had been translated completely into Japanese.  Yet, with no build tools at the time the work was completed, it was never really able to be used, and the work stalled out.

The bulk of our effort can be seen in this one .po file:
https://raw.githubusercontent.com/pfsense/pfsense/07cf6e6e0454dc730f2916e54bbf2b9a569fc812/usr/local/share/locale/ja/LC_MESSAGES/pfSense.po

The overwhelming majority of the translations were completed by Chie Taguchi.

We were able to build on top of the excellent work the Brazilian Portuguese translation, (pt_BR.ISO8859-1)- they did the heavy lifting using gettext for the interface internationalization some years ago- making the translation files simple to find, and start working with.

--
Files list:

In pfSense, the .po gettext translation files were here, for Portuguese (Brazil) and English translations,
<pfsense-repo>./usr/local/share/locale/pt_BR.ISO8859-1/LC_MESSAGES/pfSense.po
<pfsense-repo>./usr/local/share/locale/en/LC_MESSAGES/pfSense.pot

/usr/local/share/locale is not at all a good location for the UI translation files, as it resides in the FreeBSD src base.

Some place more naturally packaged with the UI:
<core>./src/www/themes/locale/
Plus,

The only remnants of pt_BR I can find in the code are currently:

$ find . -name '*pt_BR*' -print
./src/www/themes/opnsense/assets/javascripts/bootstrap-select/js/i18n/defaults-pt_BR.js
./src/www/themes/opnsense/build/js/i18n/defaults-pt_BR.js
./src/www/themes/opnsense/build/js/i18n/defaults-pt_BR.min.js
./src/www/themes/sample/assets/javascripts/bootstrap-select/js/i18n/defaults-pt_BR.js
./src/www/themes/sample/build/js/i18n/defaults-pt_BR.js
./src/www/themes/sample/build/js/i18n/defaults-pt_BR.min.js
$

Hi All,

Took me some time, and I was hoping to close this thread, but using 15.1.7-78bdb9aef cxgb still does not appear to be there.  Here's my dmesg:

http://www.nycbug.org/index.cgi?action=dmesgd&do=view&id=2680

I'll get time with the gear after next week to spend more time finding out why, I'm sorry I had very limited time with this hardware yesterday.

Best,
.ike

Hi All,

I'm failing to light up cxgb(4) Chelsio T520-CR 10Gbit fiber cards, (ixgb(4) based cards are working right now).

Running:
15.1.5-4608ae4b6 (amd64)

pfSense dmesg: (working)
http://www.nycbug.org/index.cgi?action=dmesgd&do=view&id=2656
OPNsense dmesg: (not lighting up)
http://www.nycbug.org/index.cgi?action=dmesgd&do=view&id=2657

The drivers don't seem to be compiled into the OPNSense kernel.  Looking at pfSense sources, I'm flummoxed as to where they compile them in, (they must simply be in their internal build tools).

--
I also tried 'if_cxgb_load="YES"' in /boot/loader.conf.local - to no avail, the cards still won't light.
https://www.freebsd.org/cgi/man.cgi?query=cxgb&apropos=0&sektion=4&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html

--
REQUEST FOR DIRECTION FOR WHERE TO FIX THIS (and send patches?):

Are yall' opposed to including the driver in-kernel?
- Downside: if you put one in, why not put *all* network drivers in kernel... (too fat?)
- Upside: OPNSense would support a popular card, right out the box, in-kernel

Or, should I just work on finding the casue of (and resolving) my loader.conf issue, (perhaps with the next 10.1 based build)?

Best,
.ike