主要我們提供民眾一些入山申證相關的內容要提供。

像這個部分我們沒有辦法硬性去處理，唯一能做的是，用機器翻譯的方式，把公告的內容來做翻譯。接著是需要林務局配合，把一些區域正規的語言名稱跟一些相關法規內容提供給我們，我們這邊英文版網站，大概可以處理完畢。

再來，很大的一塊區域是，我們各個保護區的管理單位，自己發布公告，我們也沒有硬性規定一定要寫英文的公告，但是其實保護區在申請上來說，公告的內容其實算這個網站申請滿重要的項目，因為如果地方不能申請進去，其實通常都是寫在我們的公告上面。

基本上在設計的時候，沒有考慮到任何英文相關的資訊，但是在設計上來說的話，自然保護區的申請系統，條目其實並不是非常多，而是一些網站上會有的按鈕、頁籤的相關內容，這一些問題並不大，因為可以採中英文的對照檔的方式去取代，比較大的問題是，像相關林務局的法規或者是提供給民眾相關的法規參考，或是流程圖的東西，基本上是沒有英文版的內容在上面。

（點頭）

我想要問一下，系統開發在配合的時候，到底會有一些權益上的衝突，也就是到底要聽林務局還是聽新廠商的問題，因為其實只要牽涉到資安，大家都會戰得很緊，所以我覺得會有一些問題。

不好意思，我再問一下執行面相關的問題，因為現在系統是在林務局在自己的機房裡面，他們有自己資安等級的規範，像現在的系統是讀不到任何IP的狀態，他們可能有經過一些防火牆的處理。

沒有問題了，以上。

最後一個問題是，除了一般的民眾使用外，還有一些不是管理者的權責機關，比如像各地的消防隊。

所以我們10月的目的是讓使用者可以申請？

有可能我們最後要做的是Plan A跟Plan B一起處理，他可能會花掉更多的時間，到最後還要轉共同的系統。

最後一個是查詢的問題，因為我們在系統上還是有一些比如使用者要申請舊的申請紀錄或者是一些抽籤的申請紀錄，這些應該是這個是做固定上的介面，並不是像剛剛申請介面這麼大的彈性或者是結構化的東西。

我想提出的是，我們這邊不只是要做一個申請API，還有一個審查的部分。

但是審查的操作介面是在新的系統上嗎？

會用mail跟他講。

不是，是到申請流程有一個key，然後再用這個key跑一次。

這個地方倒是沒有什麼太大的問題，想要詢問的問題是，審查的部分，像林管處可能對使用者要求需要補件或什麼，如果倒回原本的申請畫面？

沒有。

基本上我們的申請程序有五個階段，除非有一些地方申請是需要抽籤的，會發送他的狀態怎麼樣，然後再請使用者依據連結回來看申請的狀態，或是審查人自動發信跟民眾講說缺少了什麼，然後再請民眾到系統上去修改申請的狀態。

第三個問題是，因為到目前為止只有討論到申請的部分，但是整個保護區的申請流程是連續性的流程，關於審查的部分跟民眾抽籤的部分都沒有討論到，我想問的是，當民眾申請完之後，在各地的林管處說這個使用者要修改等，或者不允許進入的時候，這些資訊也是在新的平台嗎？

對。

對我們來講，對方提供申請的資料輸入的資料結構裡面，有帶使用者上傳的連結，我這邊就可以處理了。

另外一個問題，他們在申請保護區的時候，需要提供一些外部的附加檔案，這一種外部的附加檔案是由廠商來提供或者是我這邊也要去建一個API跟廠商對接來取得相關的資料？

對，

所以遇到這樣的問題，如果以API提供給外部廠商去存取的話，就需要他們去解析我們的申請設定檔的項目內容，才能對應給我們需要的資料，這個是我們對於API方案的要求。

基本上我們申請的區域是有法規固定要填欄位，像申請的區域、申請進入及離開的時間，還有活動範圍，但是還有部分像行程或者是申請目的，或者是災難的處理方式，這一種東西是額外的欄位，我們提供的彈性其實是給各個保護區給申請的人提供哪一些東西，所以像那一些欄位會封裝成一個結構化的資料放在同一個欄位裡面，在底層資料庫裡面會放在一個欄位，也就是申請縫的欄位裡面，基本上我們的頁面設計是只要有欄位都是使用者必填的，這是基礎的設定。

如果是Plan B的話，我們沒有辦法控制各個林管區申請的需求，因為他們可能會依據他們的業務需求來調整他們的欄位或者是調整金額的東西，所以以Plan B的話，我們沒有辦法保證網站的架構是相同的。

為了因應這一種方式，我們在申請的頁面時，會從後台去把那一些管理人的設定成一個可以生成頁面的設定檔，想要問的是，如果以採API的方式，這個問題可能會比較慢，需要API對接的廠商去理解生成的申請設定檔，而且是必須要把必填的欄位來填滿。

大家好，我是保護區的維護廠商，我有一些問題需要釐清的是，因為我們的保護區系統其實是由林務局這邊所統籌，但是管理人其實是各個林務單位，還有一些地方政府保護區的管理單位，所以後台的管理人其實是滿多個，以至於我們在表單設計上來說的話，會依據各個不同的單位，他們去調整申請的內容。